Staying on top of Fedora’s release cycle without breaking your server

We’ve written before about why Fedora’s roughly 13-month support window is worth thinking hard about before you choose it for a server (see What is Fedora, and is it actually a good fit for a server?). If you’ve already got a Fedora VPS running and you’re keeping it, this post is the practical follow-up: how to track when your release goes end-of-life, and how to upgrade in place before it does.

Check what you’re currently running

Find your current Fedora release with either of these:

cat /etc/fedora-release
rpm -E %fedora

The first gives you a human-readable line like “Fedora release 43 (Forty Three)” (Fedora dropped release nicknames after Fedora 42 “Adams” – current releases just repeat the number as the parenthetical); the second just prints the version number, which is handy for scripting.

Find out when it goes end-of-life

Fedora releases roughly every six months, in spring and autumn, and each release is supported for about 13 months – in practice, until roughly a month after the release two versions ahead of it ships. That means only two Fedora releases are supported at any given time; everything older is unpatched.

Don’t guess your EOL date – check it. The Fedora Project publishes current release lifecycle dates on its wiki, and third-party trackers like endoflife.date maintain an up-to-date table for Fedora specifically. Check either before you assume you’ve got time left.

Why running past EOL is a real risk

Once a release is end-of-life, Fedora stops shipping updates for it entirely – no security patches, no bug fixes, nothing. dnf will typically still run against an EOL release’s repositories for a while (until the mirrors are archived or pulled), which means it can look like everything’s fine when it isn’t. A server sitting on an EOL Fedora release with any public-facing service – SSH, a web server, anything – is running with known, unpatched vulnerabilities. That’s not a theoretical risk on a VPS with a public IP; it’s actively worse than running an older but supported distribution.

Upgrading in place with dnf system-upgrade

Fedora supports in-place upgrades between releases using the system-upgrade plugin, which works with both dnf4 and dnf5 (dnf5 is the default on current Fedora releases – see Managing packages with dnf for background on the dnf4/dnf5 transition). The plugin is designed to move you forward one or two releases at a time, not to jump several versions in one go.

Before you start: take a snapshot or backup if your hosting setup allows it, and make sure the server has enough free disk space – the upgrade downloads a full set of new packages before it touches anything.

Step 1 – Update your current system fully first. Don’t skip this; upgrading from a stale system is a common source of failed upgrades.

sudo dnf upgrade --refresh

Reboot if a kernel update was installed, then continue.

Step 2 – Make sure the system-upgrade plugin is available. On most current Fedora installs it’s already included with dnf5’s plugin set. If the command in the next step isn’t recognised, install it explicitly:

sudo dnf install dnf5-plugin-system-upgrade

Step 3 – Download the target release. Replace 44 with the release you’re upgrading to:

sudo dnf system-upgrade download --releasever=44

This resolves and downloads every package needed for the new release without touching your running system. It’ll flag any dependency conflicts here rather than mid-upgrade, so read the output before continuing. If you hit unresolved dependencies and you’re confident it’s safe to do so, you can add --allowerasing to let dnf remove conflicting packages as part of the resolution.

Step 4 – Reboot to apply the upgrade.

sudo dnf system-upgrade reboot

The server reboots into a special offline mode and works through installing the downloaded packages before booting normally again. This can take a while depending on how many packages changed – don’t interrupt it. On a remote VPS, expect to lose your SSH session for the duration; give it time before assuming something’s gone wrong.

Step 5 – Verify afterwards. Once it’s back up, confirm the upgrade actually completed and check for issues:

cat /etc/fedora-release
sudo dnf system-upgrade log

Check that any services you run (web server, database, custom applications) came back up correctly – an OS upgrade can occasionally change default configs or drop deprecated packages, so this is worth a proper check rather than a glance.

A realistic way to keep on top of this

The honest answer here is that this needs to become a routine, not a one-off. A few practical options:

• Put a recurring calendar reminder in a few weeks before each Fedora release ships (spring and autumn), prompting you to check your current release’s EOL date and schedule the upgrade.
• Upgrade one release behind the very latest rather than always chasing the newest – it gives you a slightly longer runway and lets any early post-release bugs get fixed before you touch it.
• If you find yourself dreading this every year, that’s a genuine signal, not a personal failing. If you don’t have a specific reason to need Fedora’s bleeding-edge packages, AlmaLinux gives you the same RHEL-family tooling and workflow with a support window measured in years rather than months. See What is AlmaLinux, and what’s it best for? if that sounds like a better fit.

Fedora’s release cycle isn’t a flaw to work around – it’s the trade-off you signed up for by choosing it. Staying ahead of it with a bit of routine maintenance is entirely manageable; ignoring it is how servers end up running unpatched for months without anyone noticing.