A Complete Guide to the OpenShift Lifecycle and Support Phases

Release cadence 

Red Hat follows the Semantic Versioning (SemVer) format, typically represented as x.y.z. Each element of the version represents the scope of changes and the support level:

• Major (x) version: The first number in a semantic version is called the major version and represents the evolution of the fundamental architecture of the API. You increment this when there are breaking or incompatible API changes. When this is increased, the minor and patch versions are reset to zero.
• Minor (y) version: Minor version changes include primary feature releases or backward-compatible changes to the API. In Red Hat OpenShift, each y-stream introduces a new Kubernetes version. A new y-stream release may also introduce API deprecations. 
• Patch (z) version: Patch versions are frequent releases that include critical security vulnerabilities (CVEs) and high-priority bug fixes. These are low-risk updates.

Red Hat’s current major version is 4, which is where the platform moved to the Operator-based management model. There has been no major release since then. For the minor releases, Red Hat follows a 4-month cadence. Patch releases are often weekly.   

RHOCP’s odd-numbered releases are generally referred to as standard releases, while the even-numbered releases are called Extended Update Support (EUS) releases. For example, 4.19 is a standard release, and 4.20 is an EUS release.

Standard releases have a fixed 18-month support window: 6 months of full support starting from general availability, followed by 12 months of maintenance support.

EUS releases provide 24-48 months of support, including the standard 18 months of fixed support and an optional 30 months of additional support through EUS add-ons. The EUS add-ons come in three terms, which are described in detail below.

The following image shows product timelines for the last 8 versions, depending on the release version:

Product timelines for Red Hat OpenShift Container Platform 4 (source)

Support phases

Red Hat provides support across multiple phases based on the release version, the organization’s subscription, and the add-ons purchased. They can be broadly categorized as standard support and Extended Update Support (EUS), as alluded to above.

Standard support

Standard support has two phases:

• Full support: This phase starts at the general availability of a minor version release. It includes all security updates, bug fixes, and software enhancements. This phase may also include support for new hardware certifications and minor feature enhancements. Full support ends 6 months after general availability or 90 days after the general availability of the next minor release, whichever is later. 
• Maintenance support: This phase follows full support and lasts for 12 months. During this period, Red Hat only applies critical security advisories and urgent bug fixes to the release—a process known as backporting. For odd-numbered releases, the version reaches End of Life (EOL) at the conclusion of this phase.

Extended Update Support (EUS)

All even-numbered minor releases have the option of Extended Update Support (EUS). The EUS provides three different support options, called terms:

• EUS Add-On – Long-Life Offering – Additional Term 1: This term provides 6 months of additional support after the end of maintenance support. Red Hat premium subscriptions include this by default; standard subscription users must purchase this as an add-on. EUS term 1 support enables EUS to EUS upgrades, which otherwise would require upgrading to an odd-numbered release before the next EUS release. Maintenance is limited to critical security fixes and stability patches.
• EUS Add-On – Long-Life Offering – Additional Term 2: The duration of term 2 is 12 months and is only available via purchase. This option is recommended for large organizations with large and critical environments that have a longer migration period. Only critical and important security support, along with urgent bug support, is provided in this phase. An important point to note is that the Kubernetes version will be considerably old at this point. 
• EUS Add-On – Long-Life Offering – Additional Term 3: Term 3 also has a duration of 12 months, extending the support to 48 months since general availability. It starts at the end of term 2, and support is again limited to critical and important security advisories and urgent bugs. This phase is available only for existing installations.

The following image shows an example of two releases, odd-numbered and even-numbered, their support phases and their durations.

Red Hat support phases (source)

Lifecycle of OpenShift dependencies and related components

The lifecycle and support policies for components such as Red Hat Enterprise Linux CoreOS (RHCOS) and OpenShift operators are equally important for a stable, secure cluster. We will look into them in this section. 

Red Hat Enterprise Linux CoreOS (RHCOS)

RHCOS is the only supported operating system for the control plane nodes and follows a tightly-coupled release lifecycle with the OpenShift minor version. Upgrades to RHCOS are performed via the Machine Config Operator (MCO) during the cluster update. 

OpenShift Operator lifecycle

OpenShift Operators are independent software components that extend the capabilities of an OpenShift cluster. As they are developed and offered separately, they traditionally were able to have their own release cadences and lifecycles. To simplify this, starting with OpenShift 4.14, OpenShift operators are classified into one of three lifecycle classifications described below:

• Platform-aligned operators: These Operators share the release cycle of the OCP version and are released alongside it or within very close timelines. Upgrading an OCP version usually requires upgrading these Operators as well. OpenShift Data Foundation, Red Hat Quay, and Red Hat Advanced Cluster Management for Kubernetes are examples of platform-aligned operators.
• Platform-agnostic operators: These Operators follow their own release cycle and can result in a particular Operator version spanning multiple OCP versions. Because their lifecycles are decoupled from the core platform, multiple minor versions of these operators can run in parallel across your enterprise clusters.

Some popular examples of platform-agnostic operators include:

• Red Hat OpenShift Logging: Manages aggregation and forwarding pipelines with a release model independent of core OCP upgrades.
• TrilioVault for Kubernetes: An enterprise data protection and backup operator whose versioning and support matrices span multiple OCP releases.
• CloudNativePG (CNPG): A community-driven PostgreSQL operator that automates database lifecycles independently of the underlying OpenShift container orchestration layer.

• Rolling-stream operators: These operators also have an independent release cycle but support only a single minor version. Administrators must keep these updated frequently. Red Hat JBoss Web Server and Red Hat OpenShift Lightspeed are examples of rolling-stream operators.

The Operators have only two support phases: full support and maintenance support. The following link lists these Operator types and the Operators: https://access.redhat.com/support/policy/updates/openshift_operators. 

Managed OpenShift

The release lifecycle of OpenShift on cloud providers such as Red Hat OpenShift Service on AWS (ROSA) or Azure Red Hat OpenShift (ARO) follows an independent release schedule, but a new release usually follows the standard OpenShift closely. These managed OpenShift platforms are jointly managed by the cloud providers and Red Hat’s site reliability engineering (SRE) team. Because managed services depend on cloud providers’ services and APIs, the number of minor versions supported and the availability of long-term support are limited. 

For example, in ROSA, major versions are supported for 1 year after a new release or after their retirement. Minor versions are supported for 16 months after general availability. All patch versions of a minor version are supported as long as the minor version is. At the end of the 16 months, the cluster enters Limited support status; the SLA is no longer applicable, and the SRE team no longer actively monitors it. For clusters that are not upgraded before the deadline, the control plane is automatically upgraded to the next supported minor version, but the worker nodes are not.  

ARO, on the other hand, releases new minor versions on an extended cadence to ensure platform stability. For example, the 4.20 version released in October 2025 is the next planned ARO release on the Azure platform. It provides support for stable and EUS channels (e.g., stable-4.19 or eus-4.18). The duration of the odd-numbered stable channel is not fixed and varies from release to release. For even-numbered releases, EUS is supported for an additional 6 months. For information on the ARO release calendar and to check the end-of-life of a stable channel, visit: https://learn.microsoft.com/en-us/azure/openshift/support-lifecycle#azure-red-hat-openshift-release-calendar. 

Protecting applications and data during lifecycle phases with Trilio

While Red Hat provides tools, policies, and support for managing the platform lifecycle, the responsibility for managing the lifecycle and protecting applications, including their data, remains with platform administrators. 

Trilio for Red Hat OpenShift (based on TrilioVault) is an application-centric, agentless, and cloud-native backup and recovery solution with native integration through Operators. It can be used as a point-in-time recovery strategy between version upgrades and lifecycle phase changes to restore in the event of cluster upgrade failures or post-upgrade workload failures, or incompatibilities.  

Trilio supports complex operational workflows by allowing teams to safely test and execute migrations. For example, you can clone live applications into an isolated sandbox environment to test how old software behaves during an upgrade. It also facilitates side-by-side cluster migrations, where stateful applications are moved seamlessly to a newly deployed environment, while providing the ability to roll back changes for individual applications if an issue arises.

A plan-backup-upgrade workflow creates a reliable safety net for cluster maintenance. For workloads stuck on EOL versions with unpatched vulnerabilities, Trilio offers protection via off-cluster backups that enable fast recovery during a crisis. Since the platform is built on CRDs, your backup metadata stays portable, regardless of version changes.