Seven years after 4.0, OpenShift bumps its major version and Red Hat promises you won't have to reinstall anything. OpenShift 5, generally available since November 9, 2026, updates in place from 4.22 with the same procedure as any minor release. What does change is the support calendar, the operating system on new clusters and the role AI agents play in day-to-day operations.
What OpenShift 5 brings that matters day to day
The foundation is Kubernetes 1.36 and CRI-O 1.36. On top of that, the changes fall into three areas.
Agents for operations, with a human in the loop. OpenShift Lightspeed goes from answering questions to investigating incidents: you describe the symptom in plain language, it looks for the probable cause and proposes a fix for the administrator to review and apply. That supervised mode is generally available; the autonomous mode, where an alert kicks off the investigation on its own, is in technology preview and still waits for approval before touching the cluster. Updates follow the same split: the pre-update risk analysis is GA, and the agent that plans and runs the update is a preview. Red Hat stresses that all of these AI features are optional.
MCP as a supported channel. The OpenShift MCP server and the MCP gateway reach GA. The server integrates with OAuth and OIDC providers, enforces Kubernetes RBAC, starts read-only and tags every action for auditing; the gateway screens for personal data, prompt injection and unsafe content. This is the most useful piece if you already connect coding agents to your clusters through third-party MCP servers: now there is a supported one, governed by the same rules as the rest of the platform.
Secure by default. TLS configuration is centralized and enforced across the core platform and layered products; control-plane component namespaces get their own network policies; post-quantum cryptography lands in platform images and TLS settings; and the Red Hat build of Agent Sandbox (preview) uses Kata-based sandboxed containers to isolate agent-generated code inside VMs.
For developers, the console supports the Helm 4 SDK alongside Helm 3, clusters can authenticate against an external OIDC provider (Keycloak, Okta, Entra ID, GitLab) instead of the built-in OAuth server, and the usual operators get new versions: Service Mesh 3.5 (Istio 1.31), GitOps 1.22 and Pipelines 1.24.
What changes in the lifecycle
This is the change with the most impact if you plan platform work:
| OpenShift 4 | OpenShift 5 | |
|---|---|---|
| Standard support per release | 18 months | 24 months (12 full + 12 maintenance) |
| Long-term releases | EUS | ELC: every third release, from 5.2, up to 5 years with an add-on |
| When long-term releases ship | — | Always between June and September |
| Major releases | — | Every 3 years, about a year after each major RHEL |
ACM, Quay, OpenShift Data Foundation, OpenShift Virtualization and, from 5.0, Advanced Cluster Security also share the platform lifecycle, and there will be releases of Logging, GitOps, Pipelines, Service Mesh and cert-manager aligned with each ELC. Red Hat says a deployment with those add-ons can stay version-locked for up to five years with nothing but security patches and bug fixes. It also lists, as a plan, skip-level updates from one ELC to the next with a single node reboot.
What to check before you update
The announcement doesn't list removed APIs, but three things change how you plan:
- You can only get there from 4.22. A cluster on 4.21 or earlier has to go through 4.22 first.
- Two operating systems. A cluster updated from 4.22 stays on RHEL CoreOS 9; a fresh 5.0 install starts on RHEL CoreOS 10. If you run both kinds, you'll have nodes with different kernels and packages under the same OpenShift version. Red Hat promises mixing both inside one cluster in a future release, not in 5.0.
- Operators, one by one. The new update planner for operators shows each operator's lifecycle status, cluster compatibility and available updates in one view. Open it first: Red Hat's own example shows operators that still run but are out of support or incompatible with the cluster version.
How to update from 4.22
Red Hat frames the jump as just another minor update: same flow, no migration plan. In the words of Mike Barrett, VP of hybrid cloud platforms: "If you're used to going from 4.21 to 4.22, you can go from 4.22 to 5.0." The procedure is the usual oc one; before you start, check the cluster's health:
# Current version, channel and available updates
oc get clusterversion
oc adm upgrade
# No cluster operator degraded or mid-update
oc get clusteroperators
# Nodes ready and machine config pools with nothing pending
oc get nodes
oc get machineconfigpoolsThe exact channels and update paths to 5.0 are in the release notes and Red Hat's update path tool; the console's readiness analysis runs the same checks automatically.
Pre-production checklist
- Bring a staging cluster to 4.22 and let it settle for a few days.
- Use the operator update planner to confirm every installed operator has a 5.0-compatible, supported version; update the ones that don't first.
- Run the update readiness analysis and clear any blockers it flags.
- Decide on new clusters: a fresh 5.0 install runs RHEL CoreOS 10, so validate the DaemonSets, kernel modules and security agents you run on RHCOS 9 there.
- Update staging to 5.0, run your application tests, then repeat in production.
- Revisit your calendar: with 24 months of support and the first ELC at 5.2, teams living on a 4.x EUS can plan their next long stop.
Sources
- What's new in Red Hat OpenShift 5 (Red Hat Blog, 2026-11-09)
- Red Hat OpenShift 5 delivers innovation and predictability for the long haul (Red Hat Blog, 2026-11-09)
- Red Hat OpenShift 5 for developers (Red Hat Developer, 2026-11-09)
- Red Hat OpenShift 5 update focused on AI, extending life cycles (SDxCentral, 2026-11-09)
- Red Hat OpenShift 5 Brings AI Agents to Cluster Troubleshooting and Upgrades (Virtualization Review, 2026-11-09)