Fedora server on a VPS: the 13-month clock

How long does a Fedora release get security updates?

A Fedora server needs a version upgrade about once a year, for as long as the machine exists. Fedora publishes a new release roughly every six months. Each release is supported until about four weeks after the release two versions later, which works out to about 13 months of updates. After that date the release gets no security fixes at all. The box keeps running, with a package set nobody patches any more.

The dates make it concrete. As of August 2026 the supported releases are Fedora 43 and Fedora 44. Fedora 44 shipped on 28 April 2026, and its end of life is scheduled for June 2027. Fedora 42 shipped in April 2025 and went end of life in May 2026, four weeks after Fedora 44 arrived. A server built from a Fedora 42 image was therefore out of support thirteen months later, without anyone doing anything wrong.

Fedora against an LTS, in months

LTS means long term support: a release the vendor keeps patching for years instead of months. EOL means end of life, the date the patches stop. Here is what each project publishes for the release you would install today.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora gives you 13 months per release. An Ubuntu LTS gives 60, and an enterprise rebuild such as AlmaLinux gives 120. Read the second column as the bill. Over ten years, Fedora asks for roughly 10 upgrades of the whole operating system, against 2 on the Ubuntu LTS. The Debian figure of 36 months is its regular security support, and a separate LTS team extends most releases to about five years.

These are published support windows, checked in August 2026, not measured uptime. Why the cadences differ belongs in the difference between Ubuntu LTS and interim releases on a server. What matters here is the work each one creates for you.

What a Fedora version upgrade actually involves

DNF 5 is the default package manager since Fedora 41, and dnf runs it. The system-upgrade command is part of dnf5 itself, so there is no plugin to install first. Start from the current release, fully patched:

sudo dnf upgrade --refresh
sudo reboot

The reboot matters because the upgrade resolves against what is installed and running, so a half-applied kernel or glibc update makes the next step harder to reason about. Now stage the new release. Replace 44 with the release you are moving to:

sudo dnf system-upgrade download --releasever=44

This resolves the entire transaction and downloads every package, and it changes nothing on the running system. Expect a few thousand packages and one to three gigabytes on a small server. If dnf cannot resolve the transaction it stops here and names the package that blocked it. That is the good case, because the failure happens while the machine is still up and you still have a shell.

Then run it:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status confirms a transaction is staged and waiting. dnf system-upgrade reboot restarts the machine into an offline transaction: a minimal boot where the RPM transaction runs on its own. It works that way because replacing glibc and systemd underneath running services is how you get a half-installed system. Your server is unreachable for the whole transaction, usually several minutes on a small VPS, then it reboots again into the new release. Plan for two reboots and a window where SSH does not answer.

When it comes back:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release should print a line like Fedora release 44 (Forty Four). The log subcommand prints the transaction log from that offline boot, which is the only record of what happened while you had no shell. distro-sync pulls anything left behind onto the new release's versions. repoquery --extras lists installed packages that are in no enabled repository any more, which is where you find leftovers from a repo that never published for the new release.

Snapshot the disk before the download step. The transaction runs while you cannot see the screen, so if it fails during the offline boot, SSH is not coming back and your only way in is whatever console the provider gives you, VNC or serial. Confirm you have a console or a snapshot before you start, not after.

One more check that people skip:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

When a package ships a new default config file and you have edited the old one, RPM does not overwrite your file. It writes the packaged version beside it as .rpmnew. So your sshd or nginx keeps behaving exactly like it did on the old release, while the new defaults sit unread on disk. Read those files after every upgrade. Installing rpmconf and running sudo rpmconf -a walks them one at a time and shows you the difference.

The third-party repositories are what break the upgrade

Fedora's own packages all move together on release day. Anything from outside Fedora moves on somebody else's schedule. Most vendor repositories put $releasever in their URL, so the moment you upgrade, dnf starts asking for a path that may not exist yet.

List what you have:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

For every repository that is not Fedora's own, test it against the target release before you commit to anything:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

If the vendor has published for that release, dnf downloads the metadata and exits quietly. If not, you get a 404 for a path like https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, and the same failure will stop system-upgrade download later. In the first weeks after a Fedora release, this is the single most common reason an upgrade will not start.

You have two answers. Wait a few weeks for the vendor to publish, which is usually the right call. Or upgrade without that repository:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Disabling a repository does not remove its packages. They stay installed and unmanaged, and if they block the transaction, dnf says so. Adding --allowerasing lets dnf remove installed packages to resolve the conflict, so read the removal list before you accept it. That list is where people lose a database server they meant to keep.

What happens to a Fedora server that misses the window

Nothing happens on the day itself. The failure arrives the next time you touch the package manager. End of life releases are moved off the mirror network into the archive, so dnf upgrade fails while fetching metadata, with a 404 on the metalink URL for your release:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

The machine keeps serving traffic, which is what makes this quiet and dangerous. It receives no security updates. It also cannot install anything, so on the day an OpenSSH or nginx advisory lands, you have no supported way to patch it.

Getting out is possible and slow. You can repoint the repositories at Fedora's archive at https://dl.fedoraproject.org/pub/archive/fedora/linux/ and upgrade from there. Fedora expects a hop of one or two releases at a time, so a box four releases behind means several hops in a row, each with its own chance of failing, and each one running blind in an offline boot. On a VPS, rebuilding on a current image and moving the data across is usually the shorter and safer job, and it is the same work as the first ten minutes on a new VPS.

Automatic updates patch a release. They never upgrade it.

Fedora can install its updates on a timer:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Settings live in /etc/dnf/automatic.conf, which overrides the shipped defaults in /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates is off by default, so out of the box the timer downloads updates and installs nothing. upgrade_type chooses between default and security. reboot accepts never, when-changed or when-needed.

This keeps you current inside a release. It will never move Fedora 43 to Fedora 44, because a version upgrade is a separate, deliberate operation that reboots into an offline transaction. That is the practical gap against an LTS. On Ubuntu, unattended security upgrades carry a machine through the whole five year window with no version change at all, and the version change itself is a planned job like the 24.04 to 26.04 upgrade once every few years.

When Fedora is the right server to run

Fedora is a good pick when the newness is the point.

• You need a kernel or a userspace newer than any LTS ships: recent hardware, or a container and systemd stack that is still a year away from an enterprise release. Fedora also moves to new upstream kernels during a release, so this is not only a one-off win at install time.
• You are validating what is heading into RHEL (Red Hat Enterprise Linux). Fedora feeds CentOS Stream, which feeds RHEL, so software that builds and runs on Fedora today is being tested against the enterprise platform of a couple of years from now.
• The machine is short-lived by design. A build runner or a test box that gets destroyed in two months never meets its end of life date. The same logic covers disposable VMs you hand to coding agents, where the box is rebuilt far more often than Fedora releases.
• Someone owns the upgrade. Fedora is fine on a server with a named owner and a calendar entry. It is a poor fit for the box everyone forgot.

The middle path: current packages on a stable base

Most people who want Fedora on a server want two or three current packages, not a current operating system. Those are separable. Run an LTS or an enterprise rebuild as the base, then pull the new software in where you actually need it. A container image gives you the new version of the application on a host you never have to upgrade for it (running Docker on a VPS). A vendor repository for the single package you care about, PostgreSQL or nginx, moves that one thing forward and leaves the base alone.

The trade is honest in both directions. A container gives you a new userspace on the host's old kernel, so it does not help when the kernel is the thing you need. A vendor repository gives you one new package on a base the vendor tested less. Both leave the security updates of the base system on the LTS clock, and that clock is the part that costs you a maintenance window every year on Fedora.

If you do choose Fedora for a server, put the cycle on a calendar. When a release ships, wait a few weeks for the vendor repositories to catch up, snapshot, upgrade, then verify the services came back. That rhythm costs about an hour a year and it works. The version that fails is the one where the upgrade is remembered only because something already broke.

FAQ

How long is a Fedora release supported?

About 13 months. Fedora publishes a release roughly every six months and supports each one until about four weeks after the release two versions later. Fedora 44 shipped on 28 April 2026 with end of life scheduled for June 2027. When that date passes, the release stops receiving security updates and its packages move off the mirrors into Fedora's archive.

Can I skip a Fedora release and upgrade two versions at once?

Yes, within limits. dnf system-upgrade download --releasever= accepts a target one or two releases ahead, and jumping two at a time is exactly how a once-a-year upgrade rhythm works. Going further is not a supported path, and every extra release raises the chance that a package rename or a config format change stops the transaction. If a machine is already several releases behind and past end of life, rebuilding on a current image is normally faster than a chain of upgrades.

What happens if my Fedora server reaches end of life?

It keeps running and stops being patched. The next dnf upgrade fails with a 404 on the metalink URL for your release, because end of life releases are moved to the archive at dl.fedoraproject.org. You can repoint the repository files at that archive and upgrade in hops, or rebuild the server on a supported release. Until you do one of the two, no security update can reach the machine and no package will install.

Is Fedora a bad choice for a production server?

It is a bad default and a reasonable choice with a reason. The cost is a full operating system upgrade every year, forever, on a machine you may prefer not to touch. Pick Fedora when you need a kernel or userspace newer than an LTS ships, or when the server is short-lived by design. Pick an LTS or an enterprise rebuild when you want to patch a server for years without changing its version.