For most of two decades, the answer to “I want Red Hat Enterprise Linux without paying for it” was CentOS. It was RHEL rebuilt from source, released shortly afterwards, and functionally identical. Enormous amounts of infrastructure ran on it.
In December 2020 Red Hat ended that model. CentOS became CentOS Stream, which sits ahead of RHEL rather than behind it — a preview of the next minor release rather than a copy of the current one. That is a perfectly reasonable thing to exist and it is not what those users wanted.
Rocky Linux and AlmaLinux are the two projects that took over the vacated role. Both are free, both track RHEL releases closely, and both give you roughly ten years of support per major version without a subscription.
Where they sit
The flow, which the Fedora page covers from the other end:
Fedora → CentOS Stream → RHEL → Rocky and AlmaLinux
| Support per major version | Cost | Position | |
|---|---|---|---|
| Fedora | ~13 months | Free | Where features are proven |
| CentOS Stream | ~5 years | Free | Ahead of RHEL |
| RHEL | 10 years | Subscription (free for up to 16 machines on a developer account) | The commercial release |
| Rocky, Alma | 10 years | Free | Rebuilt from RHEL |
Ten years is the number that matters. A server built today on Rocky 10 receives security updates until 2035, with no account to register and no subscription to renew. Nothing in the Debian or Ubuntu world matches that without paying, and for infrastructure that is expected to sit still, it is a genuinely different proposition.
| Version | Released | Security support until |
|---|---|---|
| 10 | June 2025 | May 2035 |
| 9 | July 2022 | May 2032 |
| 8 | May 2021 | May 2029 |
One caveat worth knowing: these rebuilds do not offer Extended Update Support. RHEL lets a paying customer stay on, say, 9.4 and keep receiving patches for it; Rocky and Alma do not. Once 9.8 is out, 9.7 stops being updated. You must keep up with point releases within your major version — which is a dnf upgrade, not a reinstall, but it is not optional.
Rocky or Alma?
They are more alike than different, and for most purposes the honest answer is that it does not matter much. The distinction that does exist is philosophical and became visible in 2023, when Red Hat restricted public access to RHEL source code.
| Rocky Linux | AlmaLinux | |
|---|---|---|
| Founded by | Gregory Kurtzer, a CentOS co-founder | CloudLinux |
| Governance | Rocky Enterprise Software Foundation | AlmaLinux OS Foundation, community-owned |
| Goal | Bug-for-bug identical to RHEL | Binary compatible, not identical |
| Consequence | Waits for RHEL; matches exactly | Can patch faster, add hardware support |
| Commercial support | CIQ | TuxCare and partners |
Rocky prioritises being indistinguishable from RHEL. If your software vendor certifies against RHEL, or a compliance auditor wants an exact match, that is the safer answer.
Alma prioritises being useful. Having dropped the bug-for-bug goal, it can ship a security fix before RHEL does and keep support for hardware Red Hat has dropped — which has already mattered for people running older server hardware that RHEL 10 no longer supports.
Neither has given anyone cause to regret choosing it. Pick Rocky for strict compatibility, Alma if you would rather have fixes sooner, and do not spend a week deciding.
Using one
Everything in the Fedora page about dnf, SELinux and firewalld applies here, because it is the same family. The difference is that versions are frozen for years rather than months.
# Which am I on?
cat /etc/redhat-release
cat /etc/os-release
# Update
sudo dnf upgrade --refresh
# EPEL - you will want this almost immediately
sudo dnf install epel-release
# Newer versions of specific software, officially
dnf module list
sudo dnf module enable postgresql:16
sudo dnf install postgresql-serverTwo things are worth knowing on day one.
EPEL is close to mandatory. Extra Packages for Enterprise Linux is a Fedora-maintained repository of things RHEL does not ship — htop, ncdu, tmux on older releases, and a long tail of ordinary tools. It is not a third-party risk in the usual sense; it is Fedora infrastructure, and essentially every RHEL-family server has it enabled.
Modules are how you get newer software without leaving the release. Where Debian offers backports, the Red Hat family offers module streams: several supported versions of PostgreSQL, Node or PHP, each with its own lifecycle. Enable the stream you want, then install normally.
Converting an existing machine
Both projects ship tools that convert a running CentOS or RHEL system in place, without reinstalling:
# Rocky
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
# Alma
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.shThese work well and are widely used. They are also a script that replaces every package on a production server, so treat them accordingly: snapshot first, test on a clone, and have console access. The same reasoning in migrating a server without downtime applies — building fresh and moving the workload is often less exciting than converting in place.
Things that catch people out
| Symptom | Cause |
|---|---|
| Package simply does not exist | EPEL not enabled |
| Permission denied with correct permissions | SELinux — ausearch -m AVC -ts recent |
| Port closed despite the rule | firewalld needs --reload |
| Software version is years old | Working as designed; check dnf module list |
| Updates stopped arriving | Stuck on an old point release — upgrade within the major version |
| New hardware unsupported | Kernel frozen for the release; Alma is sometimes better here |
apt: command not found | It is dnf |
The SELinux and firewalld rows account for most of the frustration people arriving from Ubuntu report, and both are covered properly — SELinux in Fedora, firewalld in Linux firewalls. Neither is worth disabling.
Who should run these
Yes, if you run servers and want them to sit still for years. Ten years of free security updates, an enormous amount of vendor software certified against the RHEL platform, and a configuration that will look familiar to anyone you hire. For a database server, an application server, or anything in a regulated environment, this is the boring correct answer.
Also yes if your workplace runs RHEL and you want a lab machine that behaves identically — pair it with Fedora on your desktop for the closest match to the whole stack.
Look elsewhere if:
- You want a desktop. These are server distributions; the desktop experience is dated and unloved. Use Fedora.
- You need current software versions more than you need stability — Ubuntu moves faster, and Arch faster still.
- You are following beginner tutorials, which overwhelmingly assume Ubuntu.
- You are running containers on minimal hosts, where a ten-year lifecycle on the host matters less than it used to.
- You want the whole thing without the rebuild question — Debian gives five years free with no upstream to track at all.
Quick reference
| You want | Command |
|---|---|
| Which release | cat /etc/redhat-release |
| Update everything | sudo dnf upgrade --refresh |
| Enable EPEL | sudo dnf install epel-release |
| Newer version of one package | dnf module list, then module enable |
| What provides this command | dnf provides '*/bin/NAME' |
| Undo the last transaction | sudo dnf history undo last |
| Recent SELinux denials | sudo ausearch -m AVC -ts recent |
| Open a firewall port | sudo firewall-cmd --permanent --add-port=80/tcp && sudo firewall-cmd --reload |
Related reading
- Fedora — the upstream, plus dnf and SELinux in depth
- Debian — the other answer for servers you leave alone
- Ubuntu — what most tutorials assume instead
- Linux firewalls — firewalld, zones and the reload trap
- Securing a new server — the first hour on a fresh install
- Package management — dnf next to apt and pacman
