How Long Fedora Server Updates Go Last for VPS?

Fedora release dey get security updates for how long?

Fedora server need version upgrade about once every year, for as long as the machine dey exist. Fedora dey publish new release roughly every six months. Dem dey support each release until about four weeks after the release wey come two versions later. This one mean say e go get updates for about 13 months. After that date, the release no go get any security fix again. The box go still dey run, but nobody go patch the package set again.

The dates go make am clear. As of August 2026, Fedora 43 and Fedora 44 na the supported releases. Fedora 44 ship on 28 April 2026, and dem schedule am to reach end of life for June 2027. Fedora 42 ship for April 2025 and reach end of life for May 2026, four weeks after Fedora 44 arrive. So, server wey dem build from Fedora 42 image go lose support thirteen months later, even though nobody do anything wrong.

Fedora versus LTS, for months

LTS mean long term support: na release wey vendor go continue patch for years instead of months. EOL mean end of life, na date wey patches go stop. Na wetin each project publish for the release wey you fit 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 dey give you 13 months for each release. Ubuntu LTS dey give 60, while enterprise rebuild like AlmaLinux dey give 120. Read the second column as the work cost. For ten years, Fedora go need roughly 10 full operating system upgrades, compared with 2 for Ubuntu LTS. The Debian figure of 36 months na the regular security support period, and separate LTS team dey extend most releases to about five years.

Na published support windows be these, and dem check am for August 2026; dem no be measured uptime. The reason why the release schedules different dey for the difference between Ubuntu LTS and interim releases on a server. The important thing here na the work wey each one go create for you.

Wetin Fedora version upgrade really involve

DNF 5 na the default package manager since Fedora 41, and dnf dey run am. system-upgrade command dey inside dnf5 itself, so you no need install plugin first. If you dey come from Debian or Ubuntu box, most things wey you dey type every day get direct apt to dnf equivalent, and the version upgrade below na one of the few jobs wey no get real equivalent. Start from the current release wey don fully patch:

sudo dnf upgrade --refresh
sudo reboot

The reboot important because the upgrade dey resolve against wetin install and dey run, so half-applied kernel or glibc update go make the next step harder to understand. Now stage the new release. Replace 44 with the release wey you wan move to:

sudo dnf system-upgrade download --releasever=44

This one resolve the whole transaction and download every package, but e no change anything for the running system. Expect a few thousand packages and one to three gigabytes for small server. If dnf no fit resolve the transaction, e go stop here and name the package wey block am. That na the good case, because the failure happen while the machine still dey up and you still get shell.

Then run am:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status confirm say transaction don stage and dey wait. dnf system-upgrade reboot restart the machine into an offline transaction: na minimal boot wey RPM transaction dey run by itself. E work like that because replacing glibc and systemd underneath running services na how system fit become half-installed. Your server no go reachable for the whole transaction, usually for several minutes on small VPS, then e go reboot again into the new release. Plan for two reboots and one period wey SSH no go answer.

When e come back:

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

/etc/fedora-release suppose print line like Fedora release 44 (Forty Four). log subcommand print the transaction log from that offline boot, and na the only record of wetin happen while you no get shell. distro-sync pull anything wey remain behind onto the new release versions. repoquery --extras list installed packages wey no dey any enabled repository again, and na there you go find leftovers from repository wey never publish for the new release.

Take disk snapshot before the download step. The transaction dey run while you no fit see the screen, so if e fail during offline boot, SSH no go come back and the only way you fit enter na through any console wey provider give you, VNC or serial. Confirm say you get console or snapshot before you start, no be after.

One more check wey people dey skip:

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

When package release new default config file and you don edit the old one, RPM no dey overwrite your file. E write the packaged version beside am as .rpmnew. So your sshd or nginx go continue behave exactly as e behave for the old release, while the new defaults dey unread for disk. Read those files after every upgrade. Installing rpmconf and running sudo rpmconf -a go check dem one by one and show you the difference.

Na third-party repositories dey break the upgrade

Fedora own packages all dey move together for release day. Anything wey come from outside Fedora dey follow another person schedule. Most vendor repositories put $releasever for their URL, so as you upgrade, dnf go start ask for path wey fit never exist yet.

List wetin you get:

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

For every repository wey no be Fedora own, test am against the target release before you commit to anything:

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

If vendor don publish for that release, dnf go download the metadata and exit quietly. If not, you go get 404 for path like https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, and the same failure go stop system-upgrade download later. For the first weeks after Fedora release, na this be the most common reason upgrade no go start.

You get two options. Wait some weeks make vendor publish am, and normally na the correct choice. Or upgrade without that repository:

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

Disabling repository no remove its packages. Dem go remain installed and unmanaged, and if dem block the transaction, dnf go tell you. Adding --allowerasing go allow dnf remove installed packages to resolve the conflict, so read the removal list before you accept am. Na for that list people dey lose database server wey dem plan to keep.

Wetin go happen to Fedora server wey miss the window

Nothing go happen that day itself. The failure go show the next time you touch the package manager. Dem dey move releases wey don reach end of life comot from mirror network go archive, so dnf upgrade go fail when e dey fetch metadata, with 404 for the metalink URL for your release:

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

The machine go continue to serve network traffic, and na this one make the problem quiet and dangerous. E no go receive security updates. E still no fit install anything, so when OpenSSH or nginx advisory land, you no get supported way to patch am.

You fit still recover from the problem, but e slow. You fit point the repositories to Fedora archive for https://dl.fedoraproject.org/pub/archive/fedora/linux/ and upgrade from there. Fedora expect make you jump one or two releases at a time. So, if one box dey four releases behind, you go need several hops one after another. Each hop get chance to fail, and each one dey run blind for an offline boot. For VPS, rebuilding with current image and moving the data across usually na the shorter and safer work. Na the same work as the first ten minutes for new VPS.

Automatic updates dey patch a release. Dem no dey upgrade am.

Fedora fit install updates based on timer:

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

Settings dey for /etc/dnf/automatic.conf, wey dey override the defaults wey release with /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates dey off by default, so immediately after installation, the timer dey download updates but e no install anything. upgrade_type dey choose between default and security. reboot accepts never, when-changed or when-needed.

This one keep your system current inside one release. E no go ever move Fedora 43 go Fedora 44, because version upgrade na separate operation wey you must start deliberately, and e reboot the system to run an offline transaction. Na this be the practical gap compared with an LTS. For Ubuntu, unattended security upgrades fit carry machine through the full five-year period without any version change, while the version change itself na planned work like the 24.04 to 26.04 upgrade once every few years.

When Fedora dey make sense as server to run

Fedora na good choice when na the newness matter.

• You need kernel or userspace wey new pass wetin any LTS dey release: recent hardware, or container and systemd stack wey still get about one year before enterprise release. Fedora still dey move go new upstream kernels during release, so this no be only one-time benefit during installation.
• You dey validate wetin dey enter RHEL (Red Hat Enterprise Linux). Fedora dey feed CentOS Stream, and CentOS Stream dey feed RHEL, so software wey build and run for Fedora today dey tested against the enterprise platform wey go show for some years from now.
• The machine na short-lived one by design. Build runner or test box wey dem go destroy after two months no go ever reach end of life date. The same logic apply to disposable VMs wey you dey give coding agents, where dem dey rebuild the box much more often than Fedora releases.
• Person dey responsible for the upgrade. Fedora dey okay for server wey get named owner and calendar entry. E no good for box wey everybody don forget.

The middle path: current packages on a stable base

Most people wey want Fedora for server want two or three current packages, no be current operating system. You fit separate the two. Use LTS or enterprise rebuild as the base, then bring the new software come only for where you really need am. Container image fit give you new application version for host wey you no need upgrade because of am (running Docker on a VPS). Vendor repository for the single package wey matter to you, like PostgreSQL or nginx, fit move that one thing forward and leave the base alone.

The trade-off dey honest for both sides. Container gives you new userspace on the host old kernel, so e no go help if na the kernel be the thing wey you need. Vendor repository gives you one new package for base wey the vendor test less. Both still leave base system security updates on LTS schedule, and na that schedule dey cost you maintenance window every year for Fedora.

If you choose Fedora for server, put the release cycle for calendar. When release ship, wait some weeks make vendor repositories catch up, create snapshot, upgrade, then verify say the services come back. That routine cost about one hour every year and e dey work. The version wey fail na the one where you remember the upgrade only because something don already break.

FAQ

Fedora release dey receive support for how long?

About 13 months. Fedora dey publish one release roughly every six months, and e dey support each one until about four weeks after the release wey come two versions later. Fedora 44 release on 28 April 2026, and dem schedule am to reach end of life for June 2027. When that date pass, the release no go receive security updates again, and dem go move its packages from the mirrors go Fedora archive.

I fit skip one Fedora release and upgrade two versions at once?

Yes, but e get limit. dnf system-upgrade download --releasever= accepts target wey dey one or two releases ahead, and jumping two releases at once na exactly how once-a-year upgrade rhythm dey work. Going further no be supported path, and every extra release dey increase the chance say package rename or config format change go stop the transaction. If machine don already fall several releases behind and e don pass end of life, rebuilding am with current image normally faster than chain of upgrades.

Wetin go happen if my Fedora server reach end of life?

E go continue to run, but dem no go patch am again. The next dnf upgrade go fail with 404 for the metalink URL for your release, because dem don move end-of-life releases go the archive at dl.fedoraproject.org. You fit point the repository files to that archive and upgrade in stages, or rebuild the server with supported release. Until you do one of these two things, no security update fit reach the machine and no package go install.

Fedora na bad choice for production server?

E no be good default, but e fit make sense when you get clear reason. The cost na say you go do full operating system upgrade every year, forever, for machine wey you fit prefer not to touch. Choose Fedora when you need kernel or userspace wey newer than wetin LTS release dey provide, or when the server na short-lived by design. Choose LTS or enterprise rebuild when you want patch server for years without changing its version.