Subscribe to GEN
Login to GEN
Ubuntu Server earns its place through predictability. A long term support release arrives every two years in April, each one receives five years of standard security maintenance, and the same tooling, apt, netplan and cloud-init, builds a machine the same way on a public cloud, a hypervisor or bare metal. That is why it runs on so many of the estates we are asked to look after.
We support it independently, at our published rates, with service levels from a next business day response to 30 minutes, 24 hours a day, every day of the year. There is no contract and no subscription on each machine: you buy hours and draw against them across the whole estate.
The lifecycle is the first reason. An LTS release arrives every two years in April: 20.04, 22.04, 24.04 and now 26.04, released in April 2026. Each receives five years of standard security maintenance for the main archive, so a server's working life can be planned on the day it is built, and the next LTS is always a known quantity well before the current one runs out.
The tooling is the second. The Subiquity installer with autoinstall builds physical servers unattended, cloud-init configures cloud instances and virtual machines at first boot, and netplan declares the network configuration once, in YAML. A well run Ubuntu estate is built from configuration rather than by hand, and that is also what makes it supportable: the configuration says what each machine is meant to be.
Ubuntu is published by Canonical, which offers Ubuntu Pro and its own commercial support alongside the free distribution. Everything needed to run Ubuntu Server in production, including standard security updates for the main archive, is available without either. What a subscription adds, and where it is worth buying, is set out further down this page.
Ubuntu faults tend to follow a change: a network configuration applied, a release upgrade started, a new instance launched from a template. These are the cases that arrive most often.
A YAML indentation error, a renderer that does not match what is actually managing the interface, interface names that changed with the hardware, or netplan apply run over SSH on the only link. We recover from the console, correct the configuration and use netplan try, which rolls back on its own if the change is not confirmed. Where cloud-init wrote the file, we fix it at source so the next boot does not undo the repair.
A do-release-upgrade that stopped partway leaves a server with its packages split between two releases. We recover the package state from the console with dpkg and apt, complete the upgrade rather than starting again, then re-enable the third party sources it disabled once they publish for the new release.
"dpkg was interrupted", broken dependencies and packages held back, PPAs that no longer agree with the base system, a full /boot from old kernels never removed, and unattended-upgrades that quietly stopped applying security updates months ago.
User-data ignored because it lacks its #cloud-config header or fails validation, a datasource that is not detected, templates cloned without resetting cloud-init so new instances believe they are already configured, and autoinstall runs waiting for a confirmation nobody is there to give. We read the cloud-init logs, fix the template and prove it on a fresh instance.
snapd refreshes snaps automatically, which surprises anyone expecting every change to come through apt. We set refresh windows and holds to suit the maintenance schedule, deal with snaps stuck mid-refresh, and support the services delivered as snaps, LXD among them.
A profile denying a service after its data was moved to a new path, the classic case being a database directory relocated to a larger disk. We add the path to the profile's local override rather than disabling the profile, so the protection stays in place.
The applications on top, from Apache, nginx and PHP-FPM to MariaDB, PostgreSQL and containers, are covered on our Linux support page. If a server is down now, raise it on the HelpDesk.
Ubuntu 18.04 left standard support in 2023 and 20.04 in May 2025, and 22.04 follows in April 2027. Plenty of 18.04 and 20.04 servers are still in production, doing important work, and no longer receiving security updates under standard maintenance.
We will be straight about one point, because it decides everything else. Security patches for a release past standard support come from Canonical, through Expanded Security Maintenance (ESM) in Ubuntu Pro. We cannot supply those patches, and our support does not replace them. What we can do is the engineering for whichever of these routes is right for each machine, and most estates end up using more than one.
The right answer for most servers. A 20.04 machine moves to 22.04 and then 24.04, one LTS at a time, planned and run as described below. Where a build is too far gone for an in-place upgrade, we rebuild it on the current LTS and move the workload across.
For a machine that cannot move yet, usually because an application is tied to it: segment it, firewall it to exactly what it needs, remove any direct exposure to the internet, and watch it. That reduces the risk; it does not remove it. See legacy system support.
Ubuntu Pro extends security maintenance to ten years and covers the wider universe archive as well as main. For the machines that genuinely need to stay on an older release, it is the proper answer, and buying it for those machines rather than the whole estate keeps the cost where the need is. We help identify them and enable it.
Ubuntu is derived from Debian and shares its packaging and much of its tooling, so many server workloads move across cleanly. We build the Debian server and migrate the workload in a planned window. See Debian support.
Whichever route a machine takes, our support covers the engineering, at the same published rates and the same service levels.
do-release-upgrade moves a server from one LTS to the next, one step at a time. A 20.04 server bound for 24.04 therefore makes two upgrades, by way of 22.04, and each is a full release upgrade in its own right, with its own changes to the language runtimes, databases and packaged services the applications rely on. Treating the pair as one job, and verifying properly between them, is what keeps it to a planned window rather than an outage.
What goes wrong is predictable: PPAs and third party repositories that the upgrade disables and nobody re-enables, packages pinned or held years ago, locally changed configuration files the new package wants to replace, a full /boot, and a session that drops halfway through. We deal with each of those before the window, not during it.
Sometimes the better answer is not an upgrade at all. A server built by hand years ago can be rebuilt on 24.04 or 26.04 with autoinstall or cloud-init, so the next rebuild is repeatable, and its workload moved across in a planned window. We will say which approach suits each machine, and why. With 22.04 leaving standard support in April 2027, estates on 22.04 are best planned now.
Many organisations review what they pay per machine for vendor support, especially at renewal and at the year end. It is a reasonable question, and the honest answer is usually a mix rather than all or nothing: Ubuntu Pro on the machines that genuinely need what only Canonical provides, and independent support for the engineering across the whole estate.
Our support is bought as hours at published rates and drawn against across every machine you run, whatever the number. Where a predictable annual cost suits better, a fixed price maintenance plan, driven by our asset register, covers the patching and preventative work. We choose our partnerships carefully, and work only with vendors who leave us completely free in what we advise and recommend, so our view on where Ubuntu Pro earns its cost is exactly that.
Yes. GEN provide independent 24/7 support for Ubuntu Server across the UK, with service levels from a next business day response to 30 minutes, 24 hours a day, every day of the year. Support covers Ubuntu 20.04, 22.04, 24.04 and 26.04 LTS and older releases such as 18.04, and is delivered by in-house UK engineers with no contract.
No. GEN's support does not depend on any subscription and is bought as hours at published rates, not per machine. Ubuntu Pro is a separate product from Canonical, and it is the only source of Expanded Security Maintenance patches for releases past standard support. GEN will advise honestly on which machines, if any, genuinely need it.
Ubuntu 20.04 left standard support in May 2025, and 18.04 left it in 2023. After that point, security patches for those releases come only from Canonical, through Expanded Security Maintenance in Ubuntu Pro. The practical options are to upgrade to a supported LTS release, to contain the server with segmentation and firewalling while it is moved, to buy Ubuntu Pro for the machines that genuinely need it, or to move suitable systems to Debian. GEN carry out the engineering for any of these.
No. Security patches for Ubuntu releases past standard support are produced by Canonical and delivered only through Ubuntu Pro. GEN cannot supply them and will not suggest otherwise. What GEN provide is the engineering around them: upgrading servers to a supported release, containing those that cannot move yet, and enabling Ubuntu Pro on the machines that need to stay where they are.
Not in one step. do-release-upgrade moves a server from one LTS release to the next, so a 20.04 server reaches 24.04 by way of 22.04, with two separate release upgrades. GEN plan both as one job, take an image or snapshot before each step, and verify services, networking and AppArmor between them. Where a server is better rebuilt than upgraded, GEN will say so.
Ubuntu Pro is free for personal use on a small number of machines. Commercial use is priced per machine by Canonical. Many organisations buy it only for the machines that genuinely need ten years of security maintenance, Livepatch or cover for the universe archive, and use independent support for the engineering across the rest of the estate.
Yes. Ubuntu is derived from Debian and shares its packaging and much of its tooling, so many server workloads move across cleanly. GEN build the Debian server and migrate the workload to it in a planned window, rather than attempting to convert an Ubuntu installation in place.
No. There is no support contract, no minimum term and no notice period. Customers buy hours at published rates and use them as they need them, or take a fixed price annual maintenance plan if they prefer a predictable cost.
Our engineers are UK based and in-house, with no offshore outsourcing: the specialist who takes your case is the specialist who works it, and they hold the production experience to match the equipment in front of them. Risk is assessed before anything is changed, the SAPR method is applied to every fault, and five shifts a day mean an overnight handover is a conversation between two engineers rather than a note left in a ticket. Our AI runs on our own hardware in our own data centres, and it never writes a word you read.
There is no support contract, no minimum term and no notice period. You buy hours at our published rates, use them when you need them, and what you do not use carries over. How GEN support works sets all of it out in full.
