What’s new in Red Hat OpenShift 5

Red Hat OpenShift 5 is now generally available. The Red Hat OpenShift team always tries to bring you the most requested features while, at the same time, pushing the envelope with new opportunities. You have environments combining containers, virtual machines (VMs), and AI workloads so with this release we decided to keep things practical: it’s easy to update and adopt, features agentic workflows to make day-to-day tasks more efficient, offers a longer lifecycle, built in with zero-trust security and, finally, provides enhanced virtualization capabilities to run in the enterprise.

Red Hat OpenShift 5 is based on Kubernetes 1.36 and CRI-O 1.36. Whether you deploy it yourself or use it as a managed service, you still get one application platform across bare metal, virtualized, and hybrid cloud environments. We are just going to cover the highlights here but for the complete list of changes, see the Red Hat OpenShift 5 release notes.

Intelligent: Spend less time hunting, more time deciding

When an alert triggers at 2 a.m. or a high-stakes maintenance window opens, the real cost is rarely the command you run to fix it. The time sink is the triage. It is the hour spent correlating metrics, parsing scattered logs, and trying to separate real signal from routine platform noise. Red Hat OpenShift 5 moves that investigative work directly into the platform, helping operators stay focused on making critical decisions rather than getting buried in diagnostics.

Troubleshooting shifts from manual sleuthing to guided, agentic workflows. When something goes wrong, the platform walks teams through diagnosis and remediation paths in clear language. In supervised mode, Red Hat OpenShift lays out its findings, outlines the proposed next steps, and waits for your confirmation before touching anything. For teams looking to delegate more legwork, the autonomous mode available in technology preview lets the system dig deeper on its own, while still holding for final human approval before running changes. The objective is simple: get engineers to a confident action quickly, without forcing them to interpret another wall of charts alone.  

Explore the "Enable agentic alert investigations with human approval for remediation" interactive demo ➤ 

Cluster lifecycle operations get that same level of scrutiny. Rather than discovering what an update breaks mid-flight, the Red Hat Lightspeed-augmented update guidance maps out status, potential conflicts, and blast radius before change windows begin. An update agent in technology preview goes a step further, helping plan and run safer update paths when the maintenance window opens.

Figure 1. Automated cluster update readiness analysis

Explore the "Analyze Cluster Readiness with  AI in Red Hat OpenShift" interactive demo ➤ 

Everyday platform visibility changes as well. Day 2 operations should not require a dedicated observability specialist on call just to build a custom view. Administrators can now generate Perses dashboards through conversational chat, asking for the metrics they need and getting usable, production-ready panels without hand-crafting queries. 

Figure 2. Use OpenShift Lightspeed to Create Perses Dashboards

Explore the "AI-assisted troubleshooting and observability with OpenShift Lightspeed" interactive demo ➤

When AI agents take action across a cluster, they need to do so through trusted, predictable channels. The Model Context Protocol (MCP) server for Red Hat OpenShift and MCP gateway (via Red Hat Connectivity Link) reach general availability, so platform APIs and services are reachable through the MCP in a way operations and security teams can actually govern.

Explore the "Exposing and Protecting MCP servers at Scale" interactive demo ➤ 

Predictable: Plan in years, not in fire drills

Major releases are only valuable if updating and maintaining them aligns with your business timeline. Red Hat OpenShift 5 is built around that constraint where the update from Red Hat OpenShift 4.22 is described as being “uneventful” and just a new minor release update. No migration plan is needed to adopt Red Hat OpenShift 5. Updates from Red Hat OpenShift 4.22 are in-place, with payload and update tooling changes coordinated so the jump is non-disruptive.

Explore the "Update Cluster Version to 5" interactive demo ➤

Red Hat OpenShift 5 is designed to give enterprise teams operational stability, predictability, and long-term planning confidence. We're establishing a 3-year major release cadence aligned roughly 1 year following major Red Hat Enterprise Linux (RHEL) releases. We’re also extending the provided life-cycle of all 5-year releases to 24 months, consisting of 1 year of full support and 1 year of maintenance support. In addition, Extended Update Support (EUS) in Red Hat OpenShift 4 is evolving into the Extended Life Cycle (ELC) model, delivering one ELC release per year, each backed by 5 full years of enterprise support. This additional life cycle is provided via a 3-year Extended Life Cycle add-on on top of the included full and maintenance support periods. 

Figure 3. Red Hat OpenShift 4 vs. Red Hat OpenShift 5 support lifecycle

This gives you more time to schedule updates, recertify workloads, and line platform changes up with budget and application cycles when the environment demands a longer cycle. In addition, the 5-year support Extended Life Cycle also extends to optional operators including Red Hat Advanced Cluster Security, OpenShift Service Mesh, OpenShift Pipelines, and OpenShift GitOps.

Red Hat OpenShift 5’s dual Red Hat Enterprise Linux CoreOS path lets you update the platform without forcing an application stack move. When you update your OpenShift cluster from Red Hat OpenShift 4.22, you remain on Red Hat Enterprise Linux CoreOS 9, whereas a newly created OpenShift 5.0 cluster will default to Red Hat Enterprise Linux CoreOS 10. In a future release, we will allow Red Hat Enterprise Linux CoreOS 9 and Red Hat Enterprise Linux CoreOS 10 to coexist within a single cluster, so you can transition node OS versions on your schedule while staying on one OpenShift version.

Updates can sometimes be complicated when reviewing compatibility requirements between the cluster and the optional operators. The update planner for operators gives administrators a centralized view of operator updates surfacing operator lifecycle status, cluster compatibility, and available update options. In Figure 3, it shows Advanced Cluster Management is running and compatible with the cluster, however, its support ended on July 19, 2026. Meanwhile, Cluster Logging is running but incompatible with the current cluster, and it suggests an update to a newer release. The Compliance Operator is degraded, incompatible, and past its end-of-life date.

Figure 4. Update planner for operators gives a centralised view

Secure: Raise the default bar for AI-era and shared clusters

Security work that depends on every team remembering a local setting does not scale. Red Hat OpenShift 5 pushes more of the protective posture into the platform defaults and policy surfaces operators already manage.

AI workloads bring new attack surfaces that demand more than traditional pod isolation. Red Hat OpenShift 5 protects sensitive models by encrypting model weights using confidential containers, keeping sensitive IP encrypted both at rest and in use.

Running automated agents introduces clear risk because agents frequently generate and execute code that your team has never reviewed. To keep that execution safely contained, the Red Hat build of Agent Sandbox, available in technology preview, relies on OpenShift sandboxed containers to isolate agent workloads inside VMs. This establishes a hard boundary that keeps untrusted or autonomous code from gaining unrestricted access to the broader cluster.

Cryptography is also moving. Post-quantum readiness is integrated into platform images and TLS configuration, giving customers a path to prepare as quantum-resistant algorithms enter production use rather than waiting for a mad scramble later.

TLS itself becomes simpler to run consistently. Centralized, enforced TLS configuration now applies across core Red Hat OpenShift and its layered products, so teams manage policy in one place instead of chasing hard-coded or fragmented settings across components.

Shared and multi-tenant environments benefit from tighter containment by default. Tailored network policies for platform operands strengthen isolation around those components by restricting traffic in and out of the control plane operand namespaces, which reduces unintended exposure and helps limit blast radius when something goes wrong.

Virtualize: unlock smarter, optimized VM management with Red Hat OpenShift

Most enterprises still run critical applications on VMs, but managing them separately from modern applications creates unnecessary operational silos. Red Hat OpenShift Virtualization brings VMs and containers onto one platform, simplifying operations today while giving teams a path to migrate and modernize applications at their own pace. 

OpenShift Virtualization 5 leverages the powerful agentic AI capabilities built into Red Hat OpenShift, including OpenShift Lightspeed and MCP server integration, allowing administrators to provision customized VMs and automate cluster workflows using natural language prompts. 

Explore the "Intelligent Operations with Virtual Machines - OpenShift Lightspeed" interactive demo ➤ 

From an ease of use perspective, a unified interface for node-centric management consolidates host-level networking, physical and logical storage resources, high-availability status, and VM workloads into a single, intuitive pane of glass.

Data protection is significantly enhanced via storage-agnostic incremental backup with Change Block Tracking (QEMU CBT). By identifying and backing up only modified data blocks instead of processing full virtual disk images, CBT drastically lowers network overhead and minimizes operational impact on active production workloads. 

The introduction of memory-aware load balancing along with leveraging Red Hat OpenShift native swap capability optimizes hardware density by adjusting resource allocations based on actual consumption, and reclaiming dormant capacity for large live VM migrations. 

Additionally, the virtualization autopilot framework leverages Red Hat OpenShift's unique declarative foundation. Autopilot enables zero-configuration setups, prevents configuration drift, and delivers a mechanism for delivering best practices for load-aware rebalancing policies, recovery from unplanned node health issues, and pre-configured observability dashboards. 

Map your next steps to Red Hat OpenShift 5

If you are using Red Hat OpenShift 4.22, start with the supported update path and the 5-year lifecycle implications for your update calendar. If cluster operations and management  is where you spend most of your time, use the intelligent update, troubleshooting solutions, and Perses dashboards to reduce your load. If AI or multi-tenant exposure is the concern, prioritize security against your compliance and model-protection requirements. If VMs are staying, treat autopilot defaults, memory-aware balancing, and volume group snapshots as the operational baseline—not optional extras. Or if you really want, try it all out, you won’t regret the time spent.

Explore further by doing an interactive demo

Try Red Hat OpenShift 5 today

Get started today with the Red Hat Hybrid Cloud Console and take advantage of the latest features and enhancements in OpenShift. To find out what’s next, check out the following resources:

• What’s new and what’s next in Red Hat OpenShift (Product page)
• What’s new in Red Hat OpenShift 5 for developers (Red Hat Developer blog post)
• Red Hat interactive experiences
• In the clouds (YouTube Series)
• Red Hat OpenShift commons
• Red Hat Portfolio Architecture Center
• Validated patterns

The complete list of the Red Hat OpenShift 5 updates are in the . Send us feedback through your Red Hat contacts, or create an issue on GitHub.