Lifecycle and release upgrades

Module 4: Software and updates · Reading time: 11 minutes

Learning objective: After this lesson you can look up the lifecycle of your distribution, you know what "end of life" means for your server, and you can plan and carry out a release upgrade safely.

Key concepts: release, LTS, standard support, Debian LTS, Ubuntu ESM and Ubuntu Pro, end of life (EOL), /etc/os-release, do-release-upgrade, minimal and full upgrade, third-party package sources, snapshot, curl | bash

Every release has a use-by date

Automatic updates (lesson 4.2) only work as long as your distribution still makes updates for your version. Every release of Debian and Ubuntu gets security updates for a fixed period. After that it stops: your server no longer gets fixes, not even for serious vulnerabilities. This is called end of life (EOL).

You can see which version you have like this:

anna@web1:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
...

On Ubuntu, for example, it says VERSION="24.04.3 LTS (Noble Numbat)".

Debian

Debian fully supports a release for about three years. After that the Debian LTS team takes over for another two years, with security updates for the most widely used packages. For the current releases (as of November 2026, check debian.org/releases):

So Debian 12 still gets updates through LTS, but it is in its final phase. Install a new server on Debian 13.

Ubuntu

Ubuntu releases an LTS version (Long Term Support) every two years in April, with five years of standard security maintenance. With an Ubuntu Pro subscription (free for personal use on a few machines) you also get ESM (Expanded Security Maintenance), up to ten years in total.

Between the LTS releases there are interim versions (such as 25.10) with only nine months of support. They are not meant for a server that has to run for years. Always choose an LTS for a server.

What EOL means for you

A server on a release that no longer gets updates simply keeps running. That is exactly what makes it treacherous: you notice nothing until someone exploits a vulnerability that has been fixed everywhere except on your server. On top of that:

• new software (a new PHP version, a new Docker release) is no longer built for your release;
• third-party package sources stop too, often sooner;
• the longer you wait, the bigger the jump. Debian does not support skipping a release: going from 11 to 13 has to go through 12.

So put your server's EOL date in your calendar, with a reminder six months before.

Two ways: upgrade or rebuild

There are two clean routes to a new release.

1. In-place upgrade: you update the existing server to the new release. Quick, everything stays where it is, but old leftovers and your own changes come along too.
2. Rebuild: you create a new server with the new release, set up your services again (handy with the notes from lesson 10.4 or with Docker Compose, module 9), move the data over from your backup and switch the DNS (lesson 7.1). More work, but clean, and it doubles as a test of your backup.

For a small server with a few services, an in-place upgrade is fine. If it runs a lot of custom work, or the server has already been upgraded a few times, consider rebuilding.

Preparing an in-place upgrade

Make sure you have these five things before you start:

1. A snapshot in your provider's panel, right before you start, and a recent backup outside the server (module 8). A snapshot is your quick way back if the upgrade fails halfway.
2. A second way in: your provider's console. You work over SSH, and if the network settings or the SSH server change during the upgrade, you want to be able to carry on through the console. The Debian release notes say so literally: make sure beforehand that you have another way to log in.
3. Read the release notes, especially the chapter "Issues to be aware of". For Debian 13 these include, for example: /tmp now lives in memory by default, /etc/sysctl.conf is no longer read (use /etc/sysctl.d/), and /boot must be large enough.
4. Check third-party sources. Packages that do not come from Debian or Ubuntu itself can conflict during the upgrade. Look at which sources you have (ls /etc/apt/sources.list.d/) and whether the maker already has a version for the new release.
5. A session that survives a dropped connection. Start the upgrade in tmux or screen. If your internet drops, the upgrade keeps running and you pick it up again with tmux attach.

Debian: the steps

From the Debian 13 release notes, for an upgrade from 12 to 13:

root@web1:~# apt update && apt full-upgrade          # first bring the current release fully up to date
root@web1:~# sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
root@web1:~# apt update
root@web1:~# apt upgrade --without-new-pkgs          # minimal upgrade
root@web1:~# apt full-upgrade                        # full upgrade
root@web1:~# reboot

If you still use /etc/apt/sources.list, change the codename there. Switch off third-party sources temporarily during the upgrade (rename them to .disabled) and switch them back on afterwards with the codename of the new release, if the maker has one.

During the upgrade, pay attention to the questions about configuration files. If you have changed a file yourself, such as sshd_config, dpkg asks whether you want to keep your version. Keep your own version if you know why you changed it, and compare it with the new version afterwards (.dpkg-dist).

After the reboot:

anna@web1:~$ cat /etc/os-release | grep VERSION=
VERSION="13 (trixie)"
anna@web1:~$ systemctl --failed
anna@web1:~$ sudo apt autoremove

systemctl --failed (lesson 6.1) should be empty. Also check whether your websites and containers work, and whether your monitoring (lesson 8.3) is green.

Ubuntu: do-release-upgrade

Ubuntu has its own program for this:

anna@web1:~$ sudo apt update && sudo apt full-upgrade
anna@web1:~$ sudo do-release-upgrade

Two things to know. First, Ubuntu only offers an upgrade from one LTS to the next after the first point release (for example 26.04.1, a few months after April). That is deliberate: the biggest problems get fixed in the first months. Second: if you run the upgrade over SSH, do-release-upgrade tells you that it is starting an extra SSH server on a spare port, just in case. Your firewall (lesson 5.2) then has to allow that port if you need it; usually you don't, because you have the console.

The big pitfall: software from outside the distribution

Upgrades almost always go wrong on software that does not come from the distribution. Three habits make the difference:

• No curl https://... | bash. A script from the internet that you run directly as root can change anything on your server: add sources, trust keys for all sources, overwrite files. You don't know what happened, and at the next upgrade it breaks. Download such a script, read it, and preferably do the steps yourself.
• An extra source only from the maker itself, with its own key (Signed-By, lesson 4.1), and note in your server documentation why it is there.
• No loose .deb files from websites if you can get it from the distribution or the maker's source. They never get updates.

On AlmaLinux and Rocky Linux

A "major" version (9, 10) gets about ten years of updates there, and you simply update minor versions (9.6, 9.7) with dnf upgrade. An in-place jump to a new major version is possible with the ELevate tool (AlmaLinux), but many administrators still choose to rebuild when moving to a new major version.

In practice

In the WebOké VPS screen you create a snapshot before an upgrade (at most two at a time, on the same storage as your VPS) and you have the console as a second way in. Other providers use similar names: snapshot, VNC or web console, rescue. A snapshot does not replace a backup outside the server; delete it once everything works, because it grows with every change.

Summary

• Every release gets security updates for a fixed period; after that it is end of life and your server no longer gets fixes.
• Debian: about three years plus two years of LTS; Ubuntu LTS: five years plus ESM up to ten years. Always choose an LTS for a server and put the end date in your calendar.
• Prepare an upgrade with a snapshot, a backup, the console, the release notes and a tmux session.
• Debian: sources to the new codename, apt upgrade --without-new-pkgs, apt full-upgrade; Ubuntu: do-release-upgrade, after the first point release.
• Software from outside the distribution is the biggest source of upgrade problems: no curl | bash, only sources from the maker with their own key.

Quiz

Exercise

Exercise O4.3: Your upgrade plan. Find out which release your server runs and until when it gets security updates. Then make an upgrade plan: which third-party sources do you have, how do you make a snapshot and a backup, how do you get in through the console, which steps do you carry out, how do you test afterwards, and do you choose an in-place upgrade or a rebuild (with your reason)?

Further reading

• Snapshots and backups of your VPS
• Attaching your own ISO or reinstalling your VPS
• Debian releases and support periods: https://www.debian.org/releases/
• Debian 13, release notes chapter 4 (upgrading) and 5 (issues to be aware of): https://www.debian.org/releases/trixie/release-notes/
• Ubuntu, release cycle: https://ubuntu.com/about/release-cycle
• Ubuntu Server documentation, Upgrade your release: https://ubuntu.com/server/docs/how-to/software/upgrade-your-release/