Red Hat OpenShift 5: GA features, previews and the upgrade path

Level: Operations | Format: Roadmap Radar | Platforms: OpenShift self-managed, Azure Red Hat OpenShift, Red Hat OpenShift Service on AWS, OpenShift Dedicated | Reading time: about 7 minutes | Last reviewed: November 10, 2026

Red Hat made OpenShift 5 generally available on November 9, 2026, announcing it at KubeCon + CloudNativeCon North America. The pitch is one platform for virtual machines, containers and AI agents, run with help from an agentic version of OpenShift Lightspeed. The release itself is GA, but several of its most talked-about agentic features are still Technology Preview. Read the labels before you plan production work around them.

Who should read this

Platform and operations teams running OpenShift 4, architects weighing OpenShift as a home for virtual machines moving off another hypervisor, security teams who will be asked to approve AI agents acting on clusters, and anyone using a managed OpenShift service on Azure, AWS or Google Cloud.

What is OpenShift?

OpenShift is Red Hat’s enterprise Kubernetes platform. Kubernetes schedules and runs containers; OpenShift packages it with an operating system (Red Hat Enterprise Linux CoreOS), networking, security defaults, a web console, an update service and a catalog of operators, so an organization gets one supported product instead of assembling dozens of open source parts.

Think of Kubernetes as an engine and OpenShift as a car built around it, with the dashboard, brakes and service schedule included. With OpenShift Virtualization, the same car also carries virtual machines, so a team can run a legacy VM and a containerized service side by side on one cluster.

You can run it yourself on bare metal, VMware or a public cloud, or buy it as a managed service: Azure Red Hat OpenShift, Red Hat OpenShift Service on AWS (ROSA) and OpenShift Dedicated, which runs on Google Cloud and AWS.

What changed: generally available versus preview

OpenShift 5 is based on Kubernetes 1.36 and CRI-O 1.36, according to Red Hat’s What’s new in Red Hat OpenShift 5. The status of each headline feature below comes from Red Hat’s own launch posts. Where Red Hat gives no label, the table says so.

Capability	Status	What it does
Lightspeed troubleshooting from a symptom you describe	Generally available	Suggests a probable root cause and fix. In the default supervised mode it proposes steps and waits for an administrator to confirm.
Autonomous, alert-triggered troubleshooting	Technology Preview	Investigates alerts on its own, but still needs final human approval before any change.
Update risk analysis	Generally available	Pre-flight checks for API compatibility and optional operators, mapping conflicts and blast radius before an update.
Agentic updates (update agent)	Technology Preview	Prepares an update run for an administrator to review and approve.
AI-assisted installation	Developer Preview	Guided cluster installation with AI help.
Perses dashboards from chat	Generally available	Generates observability dashboards from a conversational request.
MCP server for OpenShift and MCP gateway	Generally available	Lets AI agents query and act on clusters through the Model Context Protocol, with identity, Kubernetes RBAC and audit trails. The gateway, part of Red Hat Connectivity Link, screens tool calls for prompt injection and sensitive data.
Confidential GPU support	Generally available on supported bare-metal systems	Protects model weights and data in CPU and GPU memory from infrastructure administrators.
Red Hat build of Agent Sandbox	Technology Preview	Runs untrusted agent code inside VM-isolated sandboxes.
OpenShift Virtualization 5 features	No label in the launch overview	Storage-agnostic incremental VM backup using QEMU Change Block Tracking, swap and memory-aware load balancing, and VM provisioning from natural-language prompts.
Post-quantum readiness and control-plane hardening	No label in the launch overview	Builds on existing ML-KEM hybrid key exchange with compatible TLS 1.3 clients, adds a centralized TLS policy, and applies network policies to control-plane operand namespaces.

One requirement is easy to miss. Lightspeed does not ship with a model: Red Hat’s intelligent platform post describes it as working with large language model endpoints that you provide. Red Hat also says every AI capability in OpenShift is optional and can be enabled at your own pace.

For developers, Red Hat’s OpenShift 5 for developers roundup covers the surrounding tools, including OpenShift GitOps 1.22, Pipelines 1.24, Service Mesh 3.5 with sidecar-less ambient mode, and direct authentication with external OIDC identity providers such as Microsoft Entra ID, Okta and Keycloak. That last change pairs well with the keyless access patterns in our workload identity federation explainer.

A longer, more predictable lifecycle

Red Hat is changing the support model alongside the version number:

Each OpenShift 5 release gets 24 months of included support: 12 months of full support, then 12 months of maintenance support.
The OpenShift 4 Extended Update Support model becomes an Extended Life Cycle (ELC) model, with one ELC release per year and up to five years of enterprise support through a three-year ELC add-on.
The five-year ELC also covers Red Hat Advanced Cluster Security, OpenShift Service Mesh, OpenShift Pipelines and OpenShift GitOps.
Major OpenShift releases move to a roughly three-year cadence, about a year after each major RHEL release.

Some press coverage names OpenShift 5.2 as the first ELC release. Red Hat’s launch posts do not name it, so confirm the release with your Red Hat account team before you plan around it.

The upgrade path runs through 4.22

Red Hat describes the move from OpenShift 4.22 to 5 as an in-place update, not a migration. Two details matter for planning:

Start from 4.22. The launch overview names 4.22 as the starting point. Clusters on older 4.x releases need to reach 4.22 first.
Two operating system baselines. Clusters updated from 4.22 stay on RHEL CoreOS 9, while new OpenShift 5.0 clusters default to RHEL CoreOS 10. Running CoreOS 9 and 10 nodes in one cluster is planned for a future release. Expect your fleet to carry two node operating systems for a while, with separate hardening baselines, driver and kernel module testing, and compliance evidence.

What it means on Azure, AWS and Google Cloud

Red Hat’s launch posts do not give dates for OpenShift 5 on the managed services, and managed versions usually trail the self-managed release. Microsoft’s Azure Red Hat OpenShift support lifecycle (last updated August 19, 2026) shows the gap: OpenShift 4.21 reached general availability in February 2026 and became installable on Azure Red Hat OpenShift on August 17, 2026, while 4.22 is still listed as “coming soon” and no 5.x release appears. Because the in-place path starts at 4.22, Azure Red Hat OpenShift customers face two steps before they can reach OpenShift 5.

ROSA and OpenShift Dedicated publish their own life cycle pages. Check them, not the self-managed release notes, before promising OpenShift 5 features to application teams on those services.

Where it is heading (analysis)

This section is our analysis, not Red Hat’s roadmap.

Human approval is becoming the default contract for agentic operations. Every agentic feature in OpenShift 5, including the autonomous preview, stops for a person before it changes the cluster. Expect auditors to ask for evidence of those approvals, and expect the preview features to move toward general availability over the 5.x releases.
VM consolidation onto Kubernetes keeps accelerating. Incremental backup, memory-aware balancing and natural-language provisioning target the operational gaps that kept virtualization teams on traditional hypervisors.
The model bill is yours. Because Lightspeed calls a model endpoint you provide, the token cost, data residency and retention terms of that endpoint become part of your platform design. The cost allocation questions in FinOps for AI apply to your operations tooling too.

Risk note: Under Red Hat’s Technology Preview support scope, support cases for preview features are accepted only at Severity 3 or 4, upgrades to later versions may not be seamless, and moving to the generally available release may require a reinstall. Keep autonomous troubleshooting, agentic updates and Agent Sandbox out of production clusters until they reach general availability.

What to do next

Platform and operations teams: inventory every cluster’s current 4.x version and plan the path to 4.22. Build one OpenShift 5 test cluster from 4.22 and one fresh 5.0 cluster, and compare the CoreOS 9 and CoreOS 10 node baselines.
Architects: decide which releases you will standardize on once Red Hat names the ELC releases, and map that to your change windows and hardware refresh cycles.
Security and governance: before enabling Lightspeed or the MCP server, choose the model endpoint, document what cluster data it receives, scope agent RBAC to read-only where possible, and decide who can approve agent-proposed changes.
Virtualization teams: test incremental backup with your backup vendor and storage, and confirm feature status in the OpenShift Virtualization release notes before relying on it.
Managed service customers: watch the Azure Red Hat OpenShift, ROSA and OpenShift Dedicated life cycle pages for 4.22 and 5.0 availability, and plan on the managed timeline, not the self-managed one.

For the wider conference context, see what cloud operations teams should watch at KubeCon, Ignite and re:Invent.

Official references

Coverage

Discuss this article

Are you planning the 4.22 to 5 update, or waiting for your managed service? Leave a comment below, or report an error.

Last verified: November 10, 2026.

Red Hat OpenShift 5: what is generally available, what is still preview, and how to plan the upgrade

In this article