Three major RHEL releases are carrying production workloads at the same time right now. RHEL 8 is coasting through its final maintenance years, RHEL 9 runs the bulk of enterprise fleets, and RHEL 10 has been shipping since May 2025 on a noticeably different base. Knowing exactly what separates them decides your upgrade timing, your hardware refresh plans, and which application streams you can standardize on.
This RHEL 8 vs RHEL 9 vs RHEL 10 comparison puts the three side by side: support lifecycle dates, kernel and toolchain versions, language runtimes, networking and security defaults, and the features each release dropped. For a deeper tour of the newest release on its own, see what is new in RHEL 10. This page is the side-by-side reference.
I verified every package version below inside Red Hat’s own UBI 8, UBI 9 and UBI 10 containers in August 2026, which were at RHEL 8.10, 9.8 and 10.2 at the time. Lifecycle dates come from Red Hat’s published support policy.
Release Dates and Support Lifecycle
Every major RHEL release gets ten years of standard support: five years of full support with new features and minor releases, then five years of maintenance with security and critical fixes only. Where each release sits in that window matters more than any single feature difference.
| RHEL 8 | RHEL 9 | RHEL 10 | |
|---|---|---|---|
| General availability | May 7, 2019 | May 17, 2022 | May 20, 2025 |
| Codename | Ootpa | Plow | Coughlan |
| Current release (Aug 2026) | 8.10 (final minor) | 9.8 | 10.2 |
| Full support ends | Ended May 31, 2024 | May 31, 2027 | May 31, 2030 |
| Maintenance support ends | May 31, 2029 | May 31, 2032 | May 31, 2035 |
| New minor releases | None (8.10 is the last) | Roughly every 6 months until May 2027 | Roughly every 6 months until May 2030 |
The RHEL 8 column is the one to internalize. It stopped receiving new features in May 2024, 8.10 is the last minor release it will ever see, and the security patch tap closes in May 2029 (a paid Extended Life Cycle add-on can stretch that by up to four years, at add-on pricing). Anything still on RHEL 8 in 2026 needs a migration plan this year, not in 2028.
Kernel, Toolchain and Core Userland
The honest way to compare userlands is to ask each release directly. Red Hat publishes UBI container images carrying the real RHEL package set, so one podman command settles what a spec sheet might fudge:
podman run --rm registry.access.redhat.com/ubi10/ubi rpm -q glibc systemd bash dnf rpmThe UBI 10 image reports the el10 builds:
glibc-2.39-128.el10_2.x86_64
systemd-257-23.el10_2.2.x86_64
bash-5.2.26-6.el10.x86_64
dnf-4.20.0-22.el10_2.noarch
rpm-4.19.1.1-23.el10.x86_64Running the same query against the ubi8 and ubi9 images, plus the documented kernel lines, fills out the core picture:
| Component | RHEL 8 | RHEL 9 | RHEL 10 |
|---|---|---|---|
| Kernel | 4.18 | 5.14 | 6.12 |
| x86-64 CPU baseline | x86-64 (original) | x86-64-v2 | x86-64-v3 |
| glibc | 2.28 | 2.34 | 2.39 |
| systemd | 239 | 252 | 257 |
| bash | 4.4 | 5.1 | 5.2 |
| OpenSSL | 1.1.1 | 3.5 (rebased in 9.8) | 3.5 |
python3 command | Not installed by default; installs Python 3.6 | Python 3.9 | Python 3.12 |
| GCC | 8.5 | 11.5 | 14.3 |
| DNF / RPM | 4.7 / 4.14 | 4.14 / 4.16 | 4.20 / 4.19 |
Two rows deserve a closer look. RHEL 8 keeps an internal Python 3.6 build for its own tooling and puts nothing on your PATH until you install python3 yourself, which surprises people coming from either newer release. And the OpenSSL story has quietly converged: the 9.8 update rebased RHEL 9 onto the same OpenSSL 3.5 line that RHEL 10 ships, the line that carries the post-quantum algorithms Red Hat introduced as a RHEL 10 headline feature. RHEL 8 stays on 1.1.1 forever, which is also why modern TLS tooling increasingly refuses to build there.
Language Runtimes and Application Streams
These are the default streams, meaning what a bare dnf install php gives you with no stream or version selection:
| Runtime | RHEL 8 | RHEL 9 | RHEL 10 |
|---|---|---|---|
| Python | 3.6 | 3.9 | 3.12 |
| PHP | 7.2 | 8.0 | 8.3 |
| Node.js | 10 | 16 | 22 |
| Perl | 5.26 | 5.32 | 5.40 |
| Ruby | 2.5 | 3.0 | 3.3 |
Defaults are only half the story. RHEL 8 leans on modularity for newer runtimes: its module streams reach Node.js 24 and PHP 8.2, and versioned packages like python3.12 exist alongside the ancient defaults. RHEL 9 kept modules (Node.js 18 through 24, PHP 8.1 through 8.3) but uses them far less. RHEL 10 ships zero modular content: dnf module list returns nothing but a deprecation warning, and newer runtimes arrive as plain versioned packages in later minor releases instead. If your automation still runs dnf module enable, it needs rework before the el10 jump. Third-party repositories follow the same split, and the setup differs enough that we wrote up enabling EPEL on RHEL 10 separately.
What RHEL 9 Changed From RHEL 8
RHEL 9 was an evolution rather than a rupture, but four of its changes still bite during migrations. The network-scripts package is gone entirely, so ifup and ifdown scripts stop existing and NetworkManager (nmcli, keyfiles) becomes the only supported way to configure interfaces. Setting SELINUX=disabled in /etc/selinux/config no longer works because kernel support for it was removed; disabling SELinux now requires the selinux=0 kernel argument, which is Red Hat nudging you to stop disabling it. Control groups flipped to cgroup v2 by default (v1 remained bootable via a kernel argument). And the CPU baseline moved to x86-64-v2, dropping roughly pre-2009 Intel and pre-2011 AMD processors.
The quieter changes: OpenSSL jumped from 1.1.1 to the 3.x line, which broke more legacy client software than any other single item on this page (anything pinning old engine APIs or TLS 1.0 died here). XFS gained bigtime support, making timestamps safe past 2038. exFAT filesystem support appeared. The iptables-nft and ipset packages were marked deprecated with nftables as the designated successor. None of these block an upgrade, but every one of them shows up eventually in an aging fleet.
What RHEL 10 Removes and Adds
RHEL 10 is the aggressive one. The Xorg display server is removed outright: GNOME runs Wayland only, with Xwayland bridging legacy X11 applications. cgroup v1 is removed from RHEL 10 entirely, not just defaulted away, so anything that mounts v1 hierarchies (old Java agents and container tooling are the usual suspects) must be fixed before upgrading. Network teaming is gone too. Ask el10 for the package and you get a flat refusal:
dnf info teamdThe repositories no longer carry it:
Error: No matching Packages to listTeams have to become bonds before the upgrade, and the config translates cleanly; our network bonding guide for RHEL and Rocky covers the nmcli side. Also removed: 32-bit multilib linking (Red Hat no longer builds 32-bit packages at all) and, as covered above, modular content. The iptables-nft package survived the cut, still shipping at 1.8.11 but deprecated, so treat nftables as the only long-term target.
On the additions side, RHEL 10 brings kernel 6.12, image mode (the OS delivered and updated as a bootc container image, which changes patching workflows completely), post-quantum cryptography in the TLS stack, and the Lightspeed command-line assistant, an AI helper you invoke as c "your question" straight from the shell. Whether you want an LLM in your root shell is a separate conversation, but it ships in the base repos and stays off until you install and configure it.
The CPU Baseline Gotcha
This is the difference that catches hardware budgets. RHEL 10 requires the x86-64-v3 microarchitecture level, which in Intel terms means Haswell (2013) or newer and roughly the Excavator or Zen generations for AMD. On any RHEL 9 or 10 host, the glibc loader tells you directly what the CPU supports:
/usr/lib64/ld-linux-x86-64.so.2 --help | grep -A6 "Subdirectories of glibc-hwcaps"On my el10 test box:
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4 (supported, searched)
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)Seeing x86-64-v3 in the supported list means the host can run RHEL 10. A machine that only reaches v2 tops out at RHEL 9 permanently. RHEL 8 hosts run a glibc too old for this listing, so check the CPU flags instead:
grep -q avx2 /proc/cpuinfo && echo "x86-64-v3 capable"No AVX2 means that server retires with RHEL 9 in 2032, whatever the rest of your fleet does. Worth knowing before you promise a migration date.
Upgrade Paths Between 8, 9 and 10
In-place upgrades run through the leapp utility, one major version at a time: 8.10 to 9, then 9 to 10. There is no skipping a major, so a RHEL 8 fleet headed for 10 makes the trip twice. Red Hat pins the exact supported minor-to-minor combinations in its supported in-place upgrade paths matrix, and the sane workflow is leapp preupgrade first: it produces a report of blockers (teamd configs, cgroup v1 consumers, removed packages) while the system keeps running, and you fix the list before committing to leapp upgrade.
Plenty of shops skip in-place upgrades entirely and rebuild on the new major instead. On the RHEL rebuilds, the AlmaLinux-maintained ELevate project fills the leapp role for in-place major jumps. Rocky Linux tracks the version boundaries and removals described here closely; AlmaLinux deliberately diverges in spots (its 10 line ships an x86-64-v2 build and re-added 32-bit i686 packages, softening two of the removals above). How the rebuilds differ from RHEL proper is a separate question we covered in the Rocky vs AlmaLinux vs RHEL comparison and the wider Rocky vs CentOS Stream vs RHEL vs Oracle Linux breakdown.
Which Release to Deploy in 2026
New builds go on RHEL 10 unless something concrete stops you, and the two legitimate stoppers are a vendor certification matrix that has not caught up to 10 yet, and hardware below the x86-64-v3 line. Either one parks you on RHEL 9, which remains a perfectly good place to be: full support to May 2027 and maintenance to May 2032 means a 9 deployment made today lives a full hardware cycle. If you are starting fresh, installing RHEL 10 step by step is where to begin.
Existing RHEL 9 fleets have no urgency. The upgrade to 10 gets easier with every minor release as leapp coverage widens, and waiting costs nothing until the 2027 planning horizon.
RHEL 8 is the one on a clock. Three years of security-only coverage remain, the jump to 10 is a two-hop trip, and every quarter of delay stacks more of this page’s removals into a single migration window. Start with the leapp preupgrade report on a representative host; the length of that report is your real project estimate.
