OpenShift 4.18 Maintenance Ends August 25, 2026 — Whether Patches Continue Depends on Your Subscription Tier

Published: August 10, 2026  ·  EOL Watch — deadline coverage  ·  Dates verified against Red Hat's product life-cycle data — methodology

Red Hat OpenShift 4.18 exits its maintenance support phase on August 25, 2026 — 15 days from this article's publication. Most end-of-support coverage will report that as "patches stop." For OpenShift 4.18, that framing is wrong, and the difference is worth real money and real risk either way: 4.18 is an even-numbered release, which under Red Hat's lifecycle policy makes it an Extended Update Support (EUS) release. After August 25, patches for 4.18 don't stop — they move behind the EUS entitlement. On a Premium subscription, EUS Term 1 is included and patches continue to February 25, 2027 at no extra cost. On a Standard subscription, EUS is an optional paid add-on — without it, August 25 is your last patch day.

So the same cluster, running the same version, is either seven months from its patch cliff or two weeks from it, depending on a line item in your Red Hat agreement. The first task this article gives you is administrative, not technical: find out which subscription tier your OpenShift entitlement is on. Everything else — the upgrade fork, the EUS bridge math, the landing-version comparison — follows from that answer.

What actually changes on August 25

OpenShift releases move through phases. Full support for 4.18 — the phase with feature-bearing z-stream updates and the full errata range — already ended September 17, 2025. Since then 4.18 has been in maintenance support: security fixes and selected urgent bug fixes, which every subscriber receives regardless of tier. That universal phase is what ends on August 25, 2026.

From August 26, the flow of 4.18 errata continues — Red Hat keeps building patches for the release through its EUS windows — but who receives them changes:

• Premium subscription: EUS Term 1 is included in what you already pay. Security-focused fixes continue to February 25, 2027. Nothing to buy, but note what EUS is: an update stream for staying put safely, not new features.
• Standard subscription: EUS Term 1 is an optional paid add-on. Buy it and you get the same coverage to February 25, 2027; don't, and your cluster's last 4.18 update is whatever shipped by August 25.
• Either tier, beyond Term 1: EUS Term 2 — an optional paid add-on for everyone, Premium included — extends 4.18 coverage to February 25, 2028, three years after the release's GA.

Nothing breaks on August 26. Clusters serve traffic, operators reconcile, oc works. The failure mode is the standard end-of-support one — quiet at first, structural later: a Standard-tier cluster without the add-on simply stops appearing in errata distribution, and every CVE affecting 4.18 from that day forward stays unpatched on it permanently.

Every recent OpenShift release, dated

Every date below is from our tracked lifecycle data for Red Hat OpenShift, which follows Red Hat's product life-cycle publication:

Dates from our tracked dataset, cross-checked against Red Hat's OpenShift life-cycle policy and product life-cycle data (verification pass 2026-08-10). Each version links to its own page with per-release detail. *Red Hat designates even-numbered releases as EUS releases; EUS end dates for 4.20 and 4.22 are not yet listed in the lifecycle data we track, so we leave those cells blank rather than project them.

The even/odd rhythm: why 4.18 has a safety net and 4.19 won't

Red Hat's OpenShift lifecycle policy designates even-numbered minor releases as EUS releases. That single sentence explains most of the table above:

• Even releases (4.16, 4.18, 4.20, 4.22) get the standard full-support-then-maintenance run plus the EUS tail — the tiered afterlife 4.18 is about to enter. 4.16 just completed the full arc: maintenance ended December 27, 2025, EUS closed June 27, 2026.
• Odd releases (4.17, 4.19, 4.21) stop at the end of maintenance. No EUS, no tiers, no add-on to buy. 4.17 hit that wall on April 1, 2026. 4.19 hits it on December 17, 2026 — and unlike 4.18's August date, that one is a hard cutoff for every subscription tier.

The practical consequence: even-numbered releases are where clusters can rest, and odd-numbered releases are corridors you move through. Red Hat's policy also documents an EUS-to-EUS upgrade path between even releases, designed to reduce the disruption of transiting the intermediate odd release. Fleets that plan around the rhythm hop even-to-even and treat odd releases as a passage; fleets that don't end up parked on a release like 4.19 in November, reading its December 17 date with no add-on available at any price.

The decision fork: three paths off August 25

Path 1 — upgrade to 4.19 now. The smallest possible move, and the most deceptive one. It clears the August 25 deadline, but per the table, 4.19's own maintenance support ends December 17, 2026 — a landing strip under four months long, with no EUS behind it. Taken as a destination, this converts one deadline into a nearer-term, harder one. Taken as the first hop of a longer path executed now, it's fine — the problem is only stopping there.

Path 2 — push through to 4.20, 4.21, or 4.22. The runway math, as of August 2026: 4.20 is already in maintenance and ends April 21, 2027 (~8 months); 4.21 ends August 3, 2027 (~12 months, odd-numbered, no EUS); 4.22 — the current release, GA June 9, 2026, latest z-stream 4.22.6 — runs to December 31, 2027 (~17 months) and is the next even-numbered, EUS-designated release. If you're doing the upgrade work anyway, 4.22 is the landing that buys the most time and restores the EUS safety net. 4.20 is the minimum defensible stop: even-numbered, but with only eight months of maintenance left it's a shorter rest than it looks.

Path 3 — invoke EUS on 4.18 as the bridge. Premium subscribers are already on it — nothing to do before August 25 except confirm the entitlement is active. Standard subscribers need to buy the add-on before treating February 25, 2027 as their date. Either way, EUS is a bridge with known dimensions: security-focused updates, no features, ending February 25, 2027 (or February 25, 2028 with the Term 2 add-on). It buys two quarters to run the multi-hop upgrade on a schedule you control — which is exactly what it's for, and all it's for.

Sequential upgrades: why starting late compounds

OpenShift minor-version upgrades are sequential — clusters move one minor release at a time. From 4.18, reaching 4.22 means transiting 4.19, 4.20, and 4.21 (the EUS-to-EUS path streamlines the even-to-even transit, but the intermediate releases are still part of the journey). Each hop wants the same diligence: cluster and operator health checks, layered-product and operator compatibility against the next minor, and remediation of deprecated Kubernetes APIs the next release removes.

That's the real argument against waiting. A team that starts the 4.18 → 4.22 path this month does three or four routine hops with an EUS cushion under them. A team that waits until February 2027 — the end of EUS Term 1 — does the same hops against a dead deadline, on a 4.18 base that is by then two years behind current, with every intermediate release deeper into its own maintenance countdown. The work doesn't shrink by deferring it; the margin does. This is the same compounding that plays out across the Kubernetes ecosystem's 14-month version treadmill — OpenShift's lifecycle is longer, but the sequential-upgrade constraint makes procrastination costlier, not cheaper.

We track Red Hat OpenShift and 480+ other products against vendor-verified dates — every OpenShift release, check any version in seconds, or see what else hits end of life this quarter.

Frequently Asked Questions

Related

• All Red Hat OpenShift versions with live status · OpenShift 4.18 — dates and risk score
• RHEL 10 End of Life: Every Phase Dated — Red Hat's phased lifecycle model on the OS side
• Kubernetes End of Life: Version Support Timeline and Risk Scores
• The 2026 EOL Calendar — everything else with an August date