Upgrade a Linux VPS to Ubuntu 26.04 or Debian 13 without breaking production

Ubuntu 26.04 LTS shipped in April 2026, and since September the upgrade path from 24.04 is open to everyone. Debian 13 has been the stable release since August 2025, and Debian 12 is now maintained only by the LTS team. Here is how to move your Linux VPS to the new release without turning an upgrade into a production outage: where things stand, a checklist, the commands and a rollback plan.

Where Ubuntu and Debian stand in October 2026

Figures from Canonical's release notes and Debian's LTS schedule:

Release	Released	Support	Upgrade from
Ubuntu 26.04 LTS (Resolute Raccoon)	23 April 2026, point release 26.04.1 on 27 August 2026	5 years of standard updates (April 2031), 10 years with Ubuntu Pro ESM	24.04 LTS or 25.10 only
Ubuntu 24.04 LTS	April 2024	standard support until 2029	22.04 LTS
Debian 13 (trixie)	9 August 2025 (13.7 in September 2026)	security team until 9 August 2028, then LTS until 30 June 2030	Debian 12 only
Debian 12 (bookworm)	10 June 2023	in LTS since 11 June 2026, until 30 June 2028	Debian 11

Two practical consequences:

There is no direct jump from Ubuntu 22.04. Canonical states it plainly: you must first move to 24.04 LTS (or 25.10), then to 26.04. That means two upgrades, with a reboot and testing in between.
Debian does not skip releases either. Only upgrades from the previous release are supported: a Debian 11 server goes to 12 first, then to 13.

There is no rush on an Ubuntu 24.04 VPS, which is covered until 2029. A Debian 12 server, on the other hand, now only gets fixes from the LTS team, with a narrower scope: plan the move to Debian 13 calmly rather than in a hurry in 2028.

In-place upgrade or a fresh server?

For production, the in-place upgrade is not always the safest route. You have two options:

In-place upgrade (do-release-upgrade or apt full-upgrade): fast, keeps the IP address and configuration, but the service is down during the operation and rolling back means restoring.
New VPS installed with 26.04 or 13, then cut over: you migrate the data, test at your own pace, then switch DNS. The old server stays untouched and is your instant rollback.

For a simple server, an in-place upgrade is fine if you prepare properly. With many third-party repositories or old containers, a clean reinstall is often less risky.

The checklist before touching production

1. A snapshot AND a real backup

A VPS snapshot, if your provider offers one, is the fastest way back: it freezes the whole disk. But it lives on the same infrastructure as the server and is not a backup. Do both:

a snapshot right before the operation, with services or at least databases stopped, to get a consistent state;
an off-server backup of what matters: database dumps, /etc, site directories, Docker volumes, crontabs.

# As root (sudo -i), adapt to your setup
mkdir -p /root/backup

# Database dumps
mysqldump --all-databases --single-transaction > /root/backup/mysql-all.sql
su - postgres -c pg_dumpall > /root/backup/pg-all.sql

# Configuration and installed packages
tar czf /root/backup/etc.tar.gz /etc
dpkg --get-selections '*' > /root/backup/packages.txt
apt-mark showmanual > /root/backup/packages-manual.txt

Then copy /root/backup to another machine (rsync, object storage, your own computer). A backup you have never restored is only a hypothesis: test at least one dump.

2. Check for cgroup v2 (a blocker for Ubuntu 26.04)

This is the change causing the most damage this year. systemd 259, shipped with Ubuntu 26.04, no longer supports cgroup v1 at all (legacy and hybrid hierarchies). According to Canonical's release notes:

an Ubuntu installation running cgroup v1 will not be allowed to upgrade to 26.04;
26.04 container workloads will not run on a host booted with cgroup v1;
a 26.04 host does not support containers that require cgroup v1, such as Ubuntu images older than 18.04.

Ubuntu and Debian have defaulted to cgroup v2 for several releases, but some servers were forced back to v1 to run old containers, old Docker versions or monitoring agents. Check:

stat -fc %T /sys/fs/cgroup/
# cgroup2fs  -> cgroup v2, all good
# tmpfs      -> cgroup v1 or hybrid, fix before upgrading

grep -o 'systemd.unified_cgroup_hierarchy=[0-9]' /proc/cmdline
grep -n 'cgroup' /etc/default/grub /etc/default/grub.d/* 2>/dev/null

If a systemd.unified_cgroup_hierarchy=0 parameter is lingering in your GRUB configuration, remove it, run sudo update-grub, reboot, and confirm your containers still work before the upgrade. On the Docker side, list containers and their images with docker ps -a and look for very old distributions: an image whose internal systemd predates cgroup v2 must be replaced, not worked around, because systemd 259 can no longer boot with cgroup v1, so there is no setting to bring it back on 26.04.

On Debian 13, systemd 257 already treats cgroup v1 as deprecated: the same check will save you a nasty surprise on the next upgrade.

3. List third-party repositories

Docker, PHP from an external repository, Node.js, assorted PPAs: these are what break upgrades. List them:

ls /etc/apt/sources.list.d/
grep -rhE '^(deb|URIs|Suites)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

For each one, check that it publishes packages for the target (resolute for Ubuntu 26.04, trixie for Debian 13). Docker's official repository, for example, supports both Ubuntu 26.04 and Debian 13. do-release-upgrade disables third-party sources during the operation; on Debian, that is your job. Either way, write them down so you can re-enable them afterwards.

4. Held packages

apt-mark showhold

An essential package on hold will make the upgrade fail. Debian's release notes recommend removing holds before you start (sudo apt-mark unhold package), except for a package you recompiled yourself.

5. Disk space, rescue access and a maintenance slot

Keep several GB free on / and check /boot: df -h / /boot. On Debian, apt -o APT::Get::Trivial-Only=true full-upgrade estimates the space needed once the new sources are in place.
Find your provider's rescue console (VNC console or equivalent in the customer area): it is what saves you if the network does not come back after the reboot.
Work inside tmux or screen: if your SSH connection drops, the upgrade keeps running and you can reattach.
Warn your users, lower your DNS TTLs ahead of time if you plan a cut-over, and pick a quiet time.

6. Write down the rollback plan

Decide before you start, not during: "if services are not back after X minutes, I restore the snapshot". Note where the restore option is, how long it takes and what you lose (anything written after the snapshot).

Ubuntu 24.04 to 26.04, step by step

Since 26.04.1 was released, the upgrade is offered normally: the -d flag, which was used to force it before the official opening, is no longer needed.

# 1. Fully update 24.04, then reboot if a new kernel was installed
sudo apt update && sudo apt full-upgrade
sudo reboot

# 2. Check the tool and the upgrade policy
sudo apt install update-manager-core
grep Prompt /etc/update-manager/release-upgrades   # should show Prompt=lts

# 3. Run the upgrade inside tmux
tmux new -s upgrade
sudo do-release-upgrade

When run over SSH, the tool offers to start a second SSH daemon on another port as a fallback; if you accept, open that port temporarily in your firewall. When asked about configuration files, keep your version if in doubt and compare it with the .dpkg-dist file afterwards.

If you are starting from Ubuntu 22.04, the same command takes you to 24.04. Reboot, check your services, then run do-release-upgrade again to reach 26.04.

What changes on an Ubuntu 26.04 server

Kernel 7.0 and systemd 259; 26.04 is the last release to support System V scripts: migrate them to systemd units.
sudo-rs is now the default sudo; the original sudo is still available as sudo.ws. Test scripts and playbooks that rely on unusual sudoers options.
rust-coreutils now provides the core utilities. Canonical still ships the GNU tools for compatibility gaps: test your shell scripts.
/tmp on tmpfs by default: what used to sit in /tmp now uses RAM and disappears at reboot.
OpenSSH 10.2: DSA keys are no longer supported.
Chrony is the default time daemon on new installs; on an upgraded server the switch is manual (sudo apt-mark auto systemd-timesyncd then sudo apt install chrony).
Apache and mod_php: Apache's systemd unit now sets MemoryDenyWriteExecute=yes, which breaks PHP's JIT with libapache2-mod-php. Canonical recommends switching to php-fpm, or else overriding the option with sudo systemctl edit apache2.
PostgreSQL: Canonical reports a performance regression with kernel 7.0 and recommends enabling huge pages.
Versions: PHP 8.5, MySQL 8.4 LTS. Read your applications' migration notes.

Debian 12 to Debian 13, step by step

Debian has no equivalent of do-release-upgrade: you change the APT sources, then upgrade in two stages.

# 1. Fully update Debian 12 (including the OpenSSH fix for remote upgrades)
sudo apt update && sudo apt full-upgrade
sudo reboot

The release notes warn that an interrupted SSH session during the upgrade could leave the server unreachable with bookworm's original OpenSSH: make sure you have at least version 1:9.2p1-2+deb12u7 (dpkg -l openssh-server), and work inside tmux.

Next, move your sources to the deb822 format recommended by Debian 13: a single /etc/apt/sources.list.d/debian.sources file, removing the old /etc/apt/sources.list.

sudo mv /etc/apt/sources.list /root/backup/sources.list.bookworm
sudo tee /etc/apt/sources.list.d/debian.sources <<'EOF'
Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
EOF

Add contrib or non-free to the Components line if your old configuration used them. Disable third-party repositories (rename their files to .disabled) and remove any bookworm-backports-sloppy entries, for which Debian provides no clean upgrade path.

# 2. Minimal upgrade, then full upgrade
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade

Before rebooting, check your network interface name: the move to systemd 257 can change the generated name for some network cards, and a VPS whose interface gets renamed comes back without networking. The release notes give the command to run right before the reboot:

ip -br link
udevadm test-builtin net_setup_link /sys/class/net/eth0 2>/dev/null | grep ID_NET_NAME

Replace eth0 with the name shown by ip -br link. If ID_NET_NAME differs from the current name, update /etc/network/interfaces or pin the name with a systemd .link file before rebooting. Also make sure a kernel metapackage is installed (dpkg -l 'linux-image*' | grep ^ii | grep -i meta).

After the reboot, clean up and convert any remaining sources:

sudo apt modernize-sources   # converts remaining .list files to deb822
sudo apt autoremove
apt list '?obsolete'          # packages no longer available from any repository

Debian 13 also notes that the .gpg keyring paths are now only compatibility symlinks to the .pgp files: once the upgrade is done, you can replace debian-archive-keyring.gpg with debian-archive-keyring.pgp in your sources.

What changes on a Debian 13 server

Kernel 6.12, OpenSSH 10.0 (no more DSA keys), OpenSSL 3.5, PHP 8.4, PostgreSQL 17, MariaDB 11.8, Nginx 1.26, Python 3.13.
/tmp moves to tmpfs (up to 50% of RAM by default), and /tmp and /var/tmp are cleaned regularly: a service that keeps long-lived files there must be moved.
i386 is no longer a full architecture: do not upgrade a 32-bit server.

After the reboot: the checks

lsb_release -a               # right release?
systemctl --failed           # no failed services?
journalctl -p err -b         # errors since boot
ss -tlnp                     # are the expected ports listening?
stat -fc %T /sys/fs/cgroup/  # cgroup2fs
docker ps -a                 # containers back up?

Then re-enable third-party repositories with the new release name. For Docker, it is usually enough to set Suites: resolute (Ubuntu 26.04) or Suites: trixie (Debian 13) in /etc/apt/sources.list.d/docker.sources, then run sudo apt update && sudo apt full-upgrade. Finally, test your sites and APIs from outside, your cron jobs, your automated backups and certificate renewal (sudo certbot renew --dry-run if you use Certbot).

If it breaks: rolling back

The server no longer responds: use your provider's rescue console. The most common cause is networking (interface name, Netplan) or the firewall.
A service will not start: journalctl -u service -b almost always tells you why (removed configuration option, missing PHP module, database version).
It is not fixed within the time limit you set: restore the snapshot, bring the service back online and investigate calmly on a copy. There is no clean "downgrade" for a distribution: rolling back means the snapshot or the backup.

FAQ

Can I go straight from Ubuntu 22.04 to 26.04?

No. Canonical requires going through 24.04 LTS (or 25.10) first. On a server, do two successive upgrades with testing in between.

Why does do-release-upgrade say no new release is available?

Check for Prompt=lts in /etc/update-manager/release-upgrades and make sure 24.04 is fully up to date. Also remember that a system running cgroup v1 is not allowed to upgrade to 26.04: switch to cgroup v2 first.

Is Debian 12 still safe in production?

It receives security fixes from the LTS team until 30 June 2028, but for a narrower set of packages. It is still usable, but plan your move to Debian 13.

Will my old Docker containers run on Ubuntu 26.04?

Those that require cgroup v1, such as Ubuntu images older than 18.04, will not. Update those images before upgrading, on a test server if possible.