Fedora server for VPS: how long updates dey last

How long Fedora release dey get security updates?

Fedora server need version upgrade about once every year, as long as the machine still 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 mean say e go get updates for about 13 months. After that date, the release no go get any security fixes again. The box go still dey run, but nobody go dey patch the package set again.

The dates go make am clear. As of August 2026, the supported releases na Fedora 43 and Fedora 44. Fedora 44 come out on 28 April 2026, and dem schedule its end of life for June 2027. Fedora 42 come out 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 don leave support thirteen months later, even though nobody do anything wrong.

Fedora compared with 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 the date wey patch 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 wey you go need do. For ten years, Fedora go require roughly 10 upgrades of the whole operating system, compared with 2 for Ubuntu LTS. The Debian figure of 36 months na the regular security support; separate LTS team dey extend most releases to about five years.

These na published support windows, checked in August 2026; dem no measure uptime. The reason why the release schedules different dey inside the difference between Ubuntu LTS and interim releases on a server. The important thing here na the work wey each option 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. The system-upgrade command dey inside dnf5 itself, so you no need install plugin first. Start from the current release wey get all patches:

sudo dnf upgrade --refresh
sudo reboot

The reboot important because upgrade dey resolve against wetin dey installed and running. So, if kernel or glibc update apply halfway, the next step go hard to understand. Now stage the new release. Replace 44 with the release wey you wan move go:

sudo dnf system-upgrade download --releasever=44

This go resolve the complete transaction and download every package, but e no go change anything for the running system. Expect 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. Na good situation be this, 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 e dey wait. dnf system-upgrade reboot restart the machine into offline transaction: na minimal boot where RPM transaction dey run by itself. E dey work like this because replacing glibc and systemd underneath running services fit leave system half-installed. Your server no go reachable during 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 where 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). The log subcommand dey print transaction log from that offline boot. Na the only record of wetin happen while you no get shell. distro-sync go bring anything wey remain behind onto the new release versions. repoquery --extras lists installed packages wey no dey any enabled repository again. Na there you go find leftovers from repository wey never publish for the new release.

Take snapshot of the disk 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 to 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 go overwrite your file. E go 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 on disk unread. Read those files after every upgrade. Installing rpmconf and running sudo rpmconf -a go check dem one by one and show you the difference.

Third-party repositories na dem dey break the upgrade

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

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 the 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 the vendor publish am, and usually 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 but unmanaged, and if dem block the transaction, dnf go talk so. 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 mistakenly lose database server wey dem intend keep.

Wetin go happen to Fedora server wey miss the window

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

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

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

You fit still recover, but e go slow. You fit point the repositories to Fedora archive at https://dl.fedoraproject.org/pub/archive/fedora/linux/, then upgrade from there. Fedora expect make you move one or two releases at a time. So if a 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 during an offline boot. For VPS, rebuilding with a current image and moving the data across usually na the shorter and safer work. Na the same kind work as the first ten minutes for a 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 come with am for /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates dey off by default, so when you install am fresh, the timer downloads updates but e no install anything. upgrade_type dey choose between default and security. reboot dey accept never, when-changed or when-needed.

This one keeps 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 plan deliberately and wey reboot the system into an offline transaction. Na this be the practical difference 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 job like the 24.04 to 26.04 upgrade once every few years.

When Fedora make sense as server

Fedora na good choice when na the newness matter.

• You need kernel or userspace wey newer pass anything LTS releases: recent hardware, or container and systemd stack wey still dey one year away from enterprise release. Fedora still dey move go new upstream kernels during one release, so this no be only one-time advantage when you install am.
• You dey validate wetin dey come for 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 get test against the enterprise platform wey fit come out in a couple of years.
• The machine get short lifetime by design. Build runner or test box wey dem go destroy in two months no go ever reach e end-of-life date. The same logic apply to disposable VMs wey you hand over to coding agents, where dem 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

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

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

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

FAQ

Fedora release dey get 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 end of life for June 2027. When that date reach, 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= dey accept target wey dey one or two releases ahead, and to jump two releases at once na exactly how upgrade once every year 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 fall behind by several releases and e don pass end of life, rebuilding am with current image normally faster pass chain of upgrades.

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

E go continue to run, but dem go stop patching am. The next dnf upgrade go fail with 404 for the metalink URL of your release, because dem move releases wey reach end of life go archive for dl.fedoraproject.org. You fit point the repository files to that archive again and upgrade in stages, or rebuild the server with supported release. Until you do one of the two, 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 need full operating system upgrade every year, forever, for machine wey you fit prefer make nobody touch. Choose Fedora when you need kernel or userspace wey newer pass wetin LTS release dey provide, or when the server get short lifespan by design. Choose LTS or enterprise rebuild when you want patch server for years without changing its version.