Ubuntu Server in 2026: Choosing Between LTS Releases (and Upgrading)

Answer first

• New server today? Deploy 24.04 LTS or 26.04 LTS — 26.04 if you want the new kernel and a support clock that runs to 2031, 24.04 if any third-party repository you depend on hasn't published 26.04 packages yet (check before you commit; three months after release, some still haven't).
• Running 24.04? You're fine — standard support to 2029, and the sanctioned in-place upgrade to 26.04 only opens with the 26.04.1 point release, expected August 2026. No rush; upgrade on your schedule between then and 2029.
• Running 22.04? Start planning now. Standard security maintenance ends spring 2027, and your path to 26.04 is two hops (22.04 → 24.04 → 26.04). Either schedule the hops or attach Ubuntu Pro to buy time to 2032.
• Running an interim (non-LTS) release on a server? Move to an LTS — interims get nine months of support and exist for early adopters and desktops, not production servers.

The lineup

Dates per Canonical's release cycle; month-level precision shifts occasionally, so plan in quarters, not days. Two structural notes: every LTS gets five free years of security maintenance for the main repository; the widely-used universe repository gets systematic coverage through Ubuntu Pro's ESM (free for up to five machines — more under "Ubuntu Pro" below). And mid-LTS, the HWE (hardware enablement) stack offers newer kernels on older releases — 24.04's point releases carry kernels far past 6.8, which is often all "I need newer drivers" actually requires.

What 26.04 changes for server operators

Resolute Raccoon (released 23 April 2026) is a bigger platform step than a typical LTS. The items that matter on servers:

• Linux 7.0. A version-numbering milestone more than an architectural one — upstream renumbered after 6.19, so 7.0 is the normal next kernel, not a rewrite. What you actually get versus 24.04's 6.8: two years of hardware enablement, io_uring and networking improvements, and scheduler work.
• systemd 259 removes cgroup v1 entirely. The release upgrader refuses to run on systems still using v1. Anything modern is on v2 already (mount | grep cgroup2 to confirm); the casualties are ancient Docker engines and old LXC setups — fix those before the OS upgrade, not during.
• OpenSSH 10.2 with post-quantum key exchange by default and DSA fully removed.
• APT 3.1 with the new solver and a cleaner CLI.
• Memory-safe userland: sudo-rs and Rust coreutils replace their C ancestors as defaults. Compatibility is high, but scripts that depend on obscure flag behaviour of sudo/cp/date deserve a test pass.
• Sharp edges reported so far: Postfix is no longer chrooted by default (check your config on upgrade), removable-media mounts moved from /media to /run/media (script breakage), kernel 7.0 drops very old NVIDIA driver series, and the release notes list a PostgreSQL performance regression under specific configurations — if you run a database-heavy box, read the current known issues before scheduling the move.

None of these is a reason to avoid 26.04; all of them are reasons to upgrade deliberately rather than casually.

The honest case for staying on 24.04 (for now)

• Third-party repositories lag. PPAs and vendor repos (databases, PHP, monitoring agents) publish for a new LTS on their own schedule. If apt update on 26.04 would leave any critical dependency behind, that's decisive — wait.
• The .1 rule exists for a reason. Canonical itself doesn't offer existing LTS users the upgrade until 26.04.1 (expected August 2026) — the first point release absorbs the launch-window fixes. Production fleets rarely lose anything by honouring that gate.
• Your clock isn't ticking. 24.04 is supported to 2029 free. Upgrading in late 2026 or during 2027 is a perfectly current posture.

The flip: new machines don't carry migration risk, so deploying 26.04 fresh today — where your dependencies allow — starts the longest possible support clock.

Ubuntu Pro and ESM, briefly

Ubuntu Pro converts each LTS's five years into ten (plus a "Legacy" add-on to fifteen), adds ESM coverage for the universe repository, Livepatch (reboot-less kernel security fixes), and the USG hardening tooling (CIS/DISA-STIG profiles). It's free for up to five machines, and list-priced at $500/server/year beyond that (support SLAs cost more; prices move — check current).

When it earns its keep: fleets that can't take the upgrade cadence (Pro turns "must move off 22.04 by 2027" into "by 2032"), compliance regimes that want FIPS/CIS artefacts, and anyone whose critical packages live in universe. When it doesn't: a well-tended small fleet that upgrades every LTS cycle and pulls mostly from main — the free tier covers your first five machines anyway.

Upgrading in place

The sanctioned path is do-release-upgrade, LTS to LTS, one hop at a time — 22.04 boxes go through 24.04. Mechanics, condensed (the fuller remote-server discipline is the same as in our Debian upgrade guide — the precautions transfer wholesale):

apt update && apt full-upgrade        # be fully current first
# backups + snapshot; then, inside tmux:
do-release-upgrade                    # offers 26.04 once 26.04.1 is out

Before you start: verify cgroup v2 (mount | grep cgroup2), re-check each third-party repo has a 26.04 pocket (the upgrader disables them during the run; you re-enable after), and have out-of-band console access tested — on a dedicated server, KVM-over-IP is the difference between "interesting hiccup" and "reprovision". After: systemctl --failed, service smoke tests, and re-enable your repos.

Frequently asked questions

Is Ubuntu 26.04 stable enough for production yet?

For new deployments, yes, with the standard caveat: check the current known-issues list against your workload (the PostgreSQL regression note being the obvious example) and confirm your third-party repositories publish 26.04 packages. For in-place upgrades of existing machines, Canonical's own gate is the answer — the upgrader doesn't offer 26.04 to LTS users until 26.04.1 in August 2026, and that's a sensible default for production fleets, not bureaucracy.

Should I ever run interim releases (25.10, 26.10…) on a server?

Almost never. Interims get nine months of support, which on a server means an OS migration more than once a year just to stay patched. Their purpose is to preview what the next LTS will contain. The one defensible server use is a short-lived machine that genuinely needs a feature months before the next LTS — and even then, a container or HWE kernel on the current LTS usually gets you there with less churn.

I need a newer kernel on 24.04 — must I upgrade to 26.04?

Usually not: install the HWE stack (apt install linux-generic-hwe-24.04), which tracks newer kernels through the LTS's point releases. That's the designed answer for "new hardware, stable userland". Upgrade the OS when you want the new platform — systemd, OpenSSL, language stacks — not just the kernel.

Ubuntu or something else entirely?

If you're weighing distributions rather than versions, that's a different article: Ubuntu vs Debian covers the closest alternative, and how to choose a Linux distribution maps the whole field including the RHEL family. The short version: Ubuntu's LTS cadence and Pro windows are its differentiators; if those aren't valuable to you, the field opens up.

Deploying on Serverside

We image Ubuntu dedicated servers with your choice of supported LTS in under a minute, on our ASN 55285 network with always-on DDoS mitigation and a self-service edge firewall. KVM-over-IP comes standard — which is exactly the out-of-band safety net the in-place upgrade section assumes — and when you'd rather start clean on 26.04 than upgrade in place, sub-minute reprovisioning makes fresh-install-and-restore a real strategy rather than a last resort.

After deploying: the first-hour hardening checklist, and sensible default firewall rules.