The Red Hat Enterprise Linux Life Cycle Explained

Red Hat Enterprise Linux is built around one of the longest support commitments in the industry: a major version roughly every three years, ten years of support as standard, and paid extensions beyond that. Minor releases arrive every six months and are where hardware enablement and feature updates appear. Understanding the difference between Full Support, Maintenance Support, Extended Update Support and Extended Life Cycle Support is what makes RHEL planning possible.

Majors, minors and the ten-year promise

RHEL major versions appear roughly every three years: RHEL 8 in 2019, RHEL 9 in 2022 and RHEL 10 in 2025. Each is supported for ten years, split into two phases.

Minor releases (9.4, 9.5, 10.1) arrive roughly every six months, typically in May and November, during Full Support. They are in-place updates rather than migrations, and they are where newer hardware support, updated application streams and feature additions land.

EUS and ELS

Two paid extensions change the shape of the curve.

Extended Update Support (EUS) lets you stay on a specific minor release for longer than the usual six months - generally around two years. This matters for organisations with long validation cycles, where qualifying a new minor release every six months is not realistic.

Extended Life Cycle Support (ELS) extends coverage past the ten-year mark for a limited set of packages and architectures. It is a migration aid rather than a long-term plan, intended for systems that cannot be moved before the standard window closes.

Application Streams

A significant part of the RHEL model is separating the base operating system from the software people actually run on it. Application Streams let you install several versions of a language runtime or database on the same release, each with its own life cycle:

dnf module list postgresql
dnf install @postgresql:16

A stream’s support window can be shorter than the underlying RHEL release. Checking stream end dates separately from the RHEL end date is a step that is easy to miss and expensive to discover late.

Where CentOS Stream fits

CentOS Stream sits between Fedora and RHEL. Fedora is where new technology is proven; CentOS Stream is the continuously delivered preview of the next RHEL minor release; RHEL is the stabilised, supported product.

Changes flow Fedora to CentOS Stream to RHEL. For organisations wanting to see what is coming, or to contribute changes upstream of RHEL, CentOS Stream is the place to test. It is not a like-for-like replacement for the old CentOS Linux rebuilds, since it tracks ahead of RHEL rather than behind it.

Alternatives such as AlmaLinux and Rocky Linux occupy the space that CentOS Linux used to, each with its own compatibility and support policy.

In-place upgrades

Historically, RHEL major upgrades meant a rebuild. The leapp tooling has made in-place upgrades a supported path:

dnf install leapp-upgrade
leapp preupgrade
leapp upgrade

leapp preupgrade produces a report of blockers without changing anything, which is the part worth running early. Upgrades are supported between adjacent majors and from a sufficiently recent minor release, so being on an old minor of the previous major usually means updating that first.

Planning guidance

• Know which phase you are in. The end of Full Support is the point at which hardware enablement stops, which matters if your refresh cycle brings new servers.
• Check Application Stream dates separately. The runtime you depend on may go end of life years before the operating system does.
• Decide on EUS deliberately. If your change control cannot absorb a minor release every six months, EUS is the mechanism designed for that. If it can, staying on the current minor is simpler and cheaper.
• Treat ELS as an exception. Budgeting for it routinely usually signals that migration planning started too late.
• Test with CentOS Stream. It is the closest available preview of the next minor release.

Conclusion

RHEL’s value is predictability measured in years rather than months: a major every three years, ten years of support, minor releases every six months, and paid extensions for organisations that need to move more slowly. Map your own hardware refresh and application life cycles onto the Full Support and Maintenance Support phases, check your Application Streams separately, and use leapp preupgrade long before you intend to upgrade.