Should I upgrade to cert-manager 1.19 to 1.20 Upgrade Before 1.21 Release now?

Kubernetes operators need to decide whether to move to cert-manager 1.20 now or accept a shrinking support window on 1.19 before 1.21 ships in June 2026.

Upgrade to cert-manager 1.20 now unless you're blocked on Kubernetes 1.31 or OpenShift 4.18. Only stay on 1.19 as a short deferral before 1.21 lands.

Blockers

Who this is for

Candidates

Upgrade to cert-manager 1.20 now

As of 2026-04-08, cert-manager 1.20 is the current supported release, released on 2026-03-10. The cert-manager support policy says each release is supported until the second subsequent release, and 1.20 is scheduled to remain supported until 1.22 ships. The official upgrade guide says there are no special upgrade steps required from 1.19 to 1.20 beyond the normal upgrade process. The main practical change is platform support: 1.20 supports Kubernetes 1.32 to 1.35 and OpenShift 4.19 to 4.21, so it drops the 1.19-era floor of Kubernetes 1.31 and OpenShift 4.18.

When to choose

Use this when you want the longer open source support runway and your clusters already meet the newer platform floor. It is the safer default if you expect to stay on upstream cert-manager rather than buy vendor LTS, because it avoids running into 1.19 end of life as soon as 1.21 is released.

Tradeoffs

Pros: longer support window, no special migration steps, access to 1.20 features such as ListenerSet support, Azure DNS Private Zones support, and chart-managed NetworkPolicy resources. Cons: you must already be on Kubernetes 1.32+ or OpenShift 4.19+, and you still need normal CRD/chart upgrade discipline.

Cautions

Do not upgrade to 1.20 if your estate still includes Kubernetes 1.31 or OpenShift 4.18, because those versions are supported by 1.19 but not by 1.20. If you manage CRDs separately from Helm, cert-manager docs say to apply updated CRDs first and then upgrade the chart.

Sources

Stay on cert-manager 1.19 until 1.21 is closer

As of 2026-04-08, cert-manager 1.19 is still supported, but its end of life is the release of cert-manager 1.21. The supported releases page lists 1.21 as an upcoming release scheduled for 2026-06-24, so the remaining upstream support window for 1.19 is short and still subject to that release timing. The reason to stay is platform compatibility: 1.19 supports Kubernetes 1.31 to 1.35 and OpenShift 4.18 to 4.20, which covers one version older than 1.20. There is no official project LTS for 1.19; cert-manager states the maintainers do not provide LTS releases, though some vendors offer commercial LTS for specific versions.

When to choose

Use this only if you are blocked on cluster upgrades and still need Kubernetes 1.31 or OpenShift 4.18 compatibility. It is a short deferral tactic, not a durable steady state, because upstream support ends when 1.21 releases.

Tradeoffs

Pros: preserves compatibility with older supported cluster versions and avoids an immediate cert-manager version change. Cons: shrinking upstream security and bug-fix window, no project-provided LTS for 1.19, and likely compressed future work when you later need both platform and cert-manager upgrades.

Cautions

As of 2026-04-08, this is a time-bounded hold, not a long-term support choice. If you stay on 1.19, plan the next move before the scheduled 1.21 release on 2026-06-24, and remember that only the last patch release of a branch is supported under cert-manager policy.

Sources

Facts updated: 2026-04-08
Published: 2026-04-09

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Should I upgrade to cert-manager 1.19 to 1.20 Upgrade Before 1.21 Release now?"
Missing something? Request coverage