Ubuntu 26.04 LTS Resolute Raccoon: what changes on your server and when to upgrade (or not)

The short version

Ubuntu 26.04 LTS "Resolute Raccoon" went out on April 23, 2026. It ships Linux kernel 7.0, systemd 259, standard support until April 2031 and, with Ubuntu Pro, until April 2036. This is the baseline we'll be running on new servers for the next five years, so it's worth understanding what's changed before hitting do-release-upgrade.

What's new if you're coming from 24.04

These are the versions shipped in the official 26.04 repos. I checked them on packages.ubuntu.com/resolute/:

Three changes actually move the needle for operations:

• Kernel 7.0 (released April 12, eleven days before Ubuntu itself). Improvements in io_uring, memory management and newer hardware support (Intel Xe3, NPUs, 200/400 GbE NICs). Most web servers won't notice the difference; if you run I/O-heavy workloads (large databases, queues), you will.
• systemd 259. The headline: cgroup v1 support is gone (it was removed back in systemd 258). If your server depends on legacy hierarchy setups, head to the "What breaks" section below.
• OpenSSH 10. Changes to default algorithms, DSA finally retired, post-quantum key exchange tightened. If you still have very old clients connecting over SSH, validate first.

Canonical also bakes in native support for NVIDIA CUDA and AMD ROCm, NVIDIA DOCA-OFED and TPM-backed full-disk encryption, plus Livepatch for ARM servers. If your client runs a small VPS, none of that matters; if you manage GPU servers for AI workloads, it's a major upgrade.

What breaks (and who it affects)

A Ubuntu LTS upgrade is never "click update, walk away". These are the friction points we actually see in the wild:

1. cgroup v1 is gone → old Docker and misconfigured LXC

systemd 259 no longer mounts the legacy cgroup hierarchy. That affects:

• Docker older than 20.10 (July 2020). In practice: anywhere the daemon hasn't been updated in years.
• Very old LXC/LXD configured with lxc.cgroup.* instead of lxc.cgroup2.*.
• Custom scripts that write to /sys/fs/cgroup/memory/, /sys/fs/cgroup/cpu/ and so on (the v1 paths) rather than /sys/fs/cgroup/<unit> (the unified v2 path).

If you're not sure, on the current server:

mount | grep cgroup
# If you see "cgroup2 on /sys/fs/cgroup", you're already on v2.
# If you see many lines with "cgroup on /sys/fs/cgroup/...", you're still on v1.

There's a temporary escape hatch (SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 on the kernel command line), but it's a stopgap, not a long-term plan.

2. Python 3.14 by default

Python 3.14 brings real changes: optional GIL (experimental "no-GIL" mode), interpreter performance gains and overdue deprecations. If your application drags dependencies stuck on Python 3.10 or 3.11, test thoroughly before upgrading.

3. OpenSSL 3.5 and OpenSSH 10

Anything still linked against OpenSSL 1.1 has been unsupported for years, but it does still show up occasionally. OpenSSH 10 also tightens default algorithms: if you depend on very old machines connecting in, check that their clients can still negotiate something acceptable in 2026.

4. Legacy packages retired

Each LTS leaves behind packages no longer maintained. The practical move is to run do-release-upgrade -d on a clone of the server and read the "obsolete packages" summary before touching production.

When to upgrade now

• Your server runs 22.04 LTS and standard support is about to expire (April 2027). Jumping straight to 26.04 buys you another 5 quiet years without stopping at 24.04.
• You're provisioning a new VPS or reinstalling a compromised one. There's no reason to start with 24.04 at this point.
• You need recent hardware (newer GPUs, NPUs, 200 GbE NICs) that older releases only support via external repos.
• You want to lock in the Pro support window until 2036 from the start of the cycle, not halfway through.
• The io_uring and memory improvements in kernel 7.0 matter for your demanding database workloads.

When to wait

• Your project is frozen in production and only takes critical patches. If 24.04 holds out until 2029, there's no urgency.
• You're running old Docker (< 20.10) or scripts that depend on cgroup v1 and can't refactor them in the short term.
• Your application drags dependencies pinned to Python 3.11 or earlier with no updated alternative.
• You rely on third-party PPAs that haven't published packages for 26.04 yet. The big ones (Ondrej PHP, official MariaDB, Postgres APT) usually take a few weeks to catch up.
• The server earns money every day and you'd rather wait for 26.04.1 (typically out in July/August, which clears up the loose ends of the initial X.04).

If in doubt, wait for 26.04.1. That point usually marks the moment the broader ecosystem (official Docker, Nginx PPA, PHP-FPM PPAs) is fully on board.

Painless migration checklist

This is the procedure we follow at Atenea when migrating a client VPS to a new LTS. It works and fits in a working day for a typical server.

1. Inventory the current server. dpkg -l, enabled services (systemctl list-unit-files --state=enabled), active PPAs (ls /etc/apt/sources.list.d/), cron jobs, custom scripts under /usr/local/bin/.
2. Full VPS snapshot in the provider's panel before touching anything. That's your "undo" button if things go sideways.
3. Independent backup (3-2-1 rule — more details here if you want them). The provider snapshot doesn't count as an off-site backup.
4. Clone the VPS to a temporary machine and run do-release-upgrade there first. It's the only honest way to find out what breaks before touching production.
5. Check journalctl -p err after the first boot in the clone. Any service throwing new errors will throw them in production too.
6. Validate critical services one by one: nginx/apache respond, PHP-FPM serves a page, MariaDB accepts connections, OpenSSH negotiates with your usual keys, Let's Encrypt certificates still work.
7. Check cgroup. mount | grep cgroup should show cgroup2. If your stack uses Docker, confirm the installed version is ≥ 20.10.
8. Update PPAs and external repos to their resolute packages. If one still doesn't have a package, decide whether to wait or disable it.
9. Maintenance window announced to the client. Real production migration using the tested method. Usually 30-60 minutes for a typical VPS.
10. Monitor for 24-48 hours afterwards. Most problems don't show up at boot — they appear on the next overnight cron job or the first traffic spike.

Will do-release-upgrade take you to 24.04 or 26.04 (and why it matters)

By default, do-release-upgrade offers the latest stable LTS, but the behaviour shifts between releases:

• If you're on 22.04, it will offer you 24.04 first. To reach 26.04 you have to go through 24.04, or use do-release-upgrade -d with the development option until 26.04 becomes the stable target.
• If you're on 24.04, you'll be able to jump straight to 26.04 once Ubuntu flags the upgrade path as stable (typically with 26.04.1).
• If you're on a non-LTS (24.10, 25.04, 25.10), you'll have to step through them linearly.

There's no safe shortcut to skip two LTS versions in one go. If anyone tells you otherwise, be sceptical.

Frequently asked questions

Is do-release-upgrade safe to run directly on production if everything is fine? Technically yes; in practice, not recommended. Anything depending on the server (connected clients, cron, queues, long-running jobs) can get caught mid-way. If the site is commercial, migrate in an announced window, not on a busy day.

What if I'd rather "wait for 26.04.1"? That's a perfectly reasonable stance. 26.04.1 usually ships in July/August and consolidates the patches accumulated in the first three months. For critical servers with no urgency, that wait is cheap insurance.

Does Ubuntu Pro until 2036 cost money? It's free for personal use (up to 5 machines) and paid for businesses. If you manage production servers for clients, the per-machine cost easily pays for itself the first time it prevents a security incident.

Does the cgroup v1 thing affect me if I only run nginx and PHP-FPM? Almost certainly no. nginx, PHP-FPM, MariaDB, Postgres, Redis and the whole typical web stack have been on cgroup v2 for years without issues. The risk is concentrated in old Docker, inherited LXC containers and custom scripts that touch /sys/fs/cgroup/ directly.

What about my favourite PPA (Ondrej PHP, official MariaDB, etc.) if it doesn't ship for 26.04 yet? Typically a matter of weeks. Two options in the meantime: use the packages from the official Ubuntu repository (PHP 8.5 is there, MariaDB 11.8 too) or wait it out.

Wrapping up

26.04 LTS isn't a revolution — it's a consolidation: kernel 7.0, systemd 259 free of the cgroup v1 baggage, modern crypto libraries and support through 2036 with Pro. For brand new servers, it's already the default choice. For production servers, the sensible path is: clone, test, validate, wait for 26.04.1 and migrate within an announced window.

If you've got a VPS on 20.04 or 22.04 that's due for an upgrade and you'd rather skip the clone-and-late-night-cutover routine, we can do it for you with no downtime and a clear rollback plan. Tell us what you're running and we'll point you to the right starting line.