NEW: Get project updates onTwitterandMastodon

Supported Releases

This page lists the status, timeline and policy for currently supported releases of cert-manager.

All cert-manager releases are supported at least until the release of a second subsequent version. That means there are always at least two supported versions of cert-manager at any given time, and possibly more if there's also a current Long Term Support version.

We aim to do regular releases roughly every 4 months but release dates can vary when accounting for holidays, conferences (such as KubeCon), maintainer commitments and other world events.

You don't have to wait until the next minor release to start using new features; we also aim to create regular alpha releases which - while not as thoroughly tested or stable as other releases - should be stable enough to run.

Currently supported releases

ReleaseRelease DateEnd of LifeSupported Kubernetes / OpenShift VersionsTested Kubernetes Versions
1.16Oct 03, 2024Release of 1.181.25 → 1.31 / 4.14 → 4.161.27 → 1.31
1.15Jun 05, 2024Release of 1.171.25 → 1.31 / 4.12 → 4.161.25 → 1.31
1.12 LTSMay 19, 2023May 19, 20251.22 → 1.31 / 4.9 → 4.161.22 → 1.29

cert-manager 1.12 is a Long Term Support (LTS) release sponsored by Venafi. It will continue to be supported for at least 2 years from release.

Upcoming releases

ReleaseRelease DateEnd of LifeSupported Kubernetes / OpenShift VersionsTested Kubernetes Versions
1.17Feb 03, 2025Release of 1.191.27 → 1.31 / 4.14 → 4.161.28 → 1.31

Dates in the future are not firm commitments and are subject to change.

We list cert-manager releases on GitHub, and release notes on cert-manager.io.

We also maintain detailed upgrade instructions.

Support policy

Supported vs Tested Versions of Kubernetes

In general, we aim to run regular end-to-end tests of all Kubernetes versions which we list as supported.

For various reasons, this isn't always possible; a big factor is which Kubernetes versions are supported by Kind, which is used in our end-to-end tests.

If a Kubernetes version is listed as "tested", you can be sure that we run end-to-end tests of cert-manager on that version regularly and we'd fix any issues that we saw in those end-to-end tests.

If a Kubernetes version is not listed as "tested" but is listed as "supported", we don't run tests regularly for that Kubernetes release, but we will still respond to and fix any bug reports for that version.

For example, cert-manager 1.12 LTS might list supported versions of Kubernetes as 1.22 → 1.31 but only test 1.22 → 1.29. That means that:

  • We will fix community-reported issues for cert-manager 1.12 on Kubernetes 1.30 or 1.31
  • We will not run automated tests for cert-manager 1.12 on Kubernetes 1.30 or 1.31
  • We will not generally test or fix issues for cert-manager 1.12 on Kubernetes 1.21 or earlier

What we mean by support

Our support window is four months for each release branch. In the below diagram, release-1.2 is an example of a release branch.

We offer two types of support:

For example, imagining that the latest release is v1.2.0, you can expect support for both v1.2.0 and v1.1.0.

Only the last patch release of each branch is supported.

v1.0.0 ^
Sep 2, 2020 | UNSUPPORTED
------+---------------------------------------------> release-1.0 | RELEASES
\ v
\
\ v1.1.0
\ Nov 24, 2020 ^
---------+-------------------------------> release-1.1 |
\ | SUPPORTED
\ | RELEASES
\ v1.2.0 | = the two
\ Feb 10, 2021 | last
------------+--------------> release-1.2 | releases
\ v
\
\
\
-----------> master branch
April 1, 2021

Technical support

Technical assistance is offered on a best-effort basis for supported releases only. You can request support from the community on Kubernetes Slack (in the #cert-manager channel), using GitHub Discussions or using the cert-manager-dev Google group.

Security and bug fixes

We back-port important bug fixes — including security fixes — to all currently supported releases.

Security issues

Security issues are fixed as soon as possible. They get back-ported to the last two releases, and a new patch release is immediately created for them.

Critical bugs

Critical bugs include both regression bugs as well as upgrade bugs.

Regressions are functionalities that worked in a previous release but no longer work. #4142, #3393 and #2857 are three examples of regressions.

Upgrade bugs are issues (often Helm-related) preventing users from upgrading to currently supported releases from earlier releases of cert-manager. #3882 and #3644 are examples of upgrade bugs.

Note that intentional breaking changes do not belong to this category.

Fixes for critical bugs are (usually) immediately back-ported by creating a new patch release for the currently supported releases.

Long-standing bugs

Long-standing bug: sometimes a bug exists for a long time, and may have known workarounds. #3444 is an example of a long-standing bug.

Where we feel that back-porting would be difficult or might be a stability risk to clusters running cert-manager, we'll make the fix in a major release but avoid back-porting the fix.

Breaking changes

Breaking changes are changes that intentionally break the cert-manager Kubernetes API or the command line flags. We avoid making breaking changes where possible, and where they're required we'll give as much notice as possible.

Other back-ports

We aim to be conservative in what we back-port. That applies especially for anything which could be a runtime change - that is, a change which might alter behavior for someone upgrading between patch releases.

That means that if a candidate for back-porting has a chance of having a runtime impact we're unlikely to accept the change unless it addresses a security issue or a critical bug.

We reserve the right to back-port other changes which are unlikely to have a runtime impact, such as documentation or tooling changes. An example would be #5209 which updated how we perform a release of cert-manager but didn't have any realistic chance of having a runtime impact.

Generally we'll seek to be pragmatic. A rule of thumb might be to ask:

"Does this back-port improve cert-manager, bearing in mind that we really value stability for already-released versions?"

How we determine supported Kubernetes versions

The list of supported Kubernetes versions displayed in the Supported Releases section depends on what the cert-manager maintainers think is reasonable to support and to test.

In practice, this is largely determined based on what versions of kind are available for testing, and which versions of Kubernetes are provided by major upstream cloud Kubernetes vendors including EKS, GKE, AKS and OpenShift.

We treat OpenShift EUS as a different distribution since the support periods are so much longer. We're likely to drop support for older OpenShift EUS before that release reaches EOL to increase the speed at which we can adopt newer Kubernetes features.

The table below lists the major Kubernetes distributions we check. In parentheses next to each release is the EOL for that release. EOL dates often change throughout the lifecycle of a release.

The "Oldest Kubernetes Release" is the oldest release we deemed relevant to the next cert-manager release, as of 2024-09-25

VendorOldest K8s ReleaseOther Kubernetes Releases
EKS1.28 (Nov 2024)1.29 (Mar 2025), 1.30 (Jul 2025)
GKE1.28 (Feb 2025)1.29 (Mar 2025), 1.30 (Sep 2025)
AKS1.28 (Jan 2025)1.29 (Mar 2025), 1.30 (Jul 2025), 1.31 (Nov 2025)
OpenShift 41.26 (4.13, Nov 2024)1.27 (4.14, May 2025), 1.28 (4.15, Aug 2025), 1.29 (4.16, Dec 2025)
OpenShift 4 EUS1.25 (4.12, Jan 2025)1.27 (4.14, Oct 2025), 1.29 (4.16, Jun 2026)

OpenShift

cert-manager supports OpenShift 4 based on the version of Kubernetes that each release maps to.

For convenience, the following table shows these version mappings:

OpenShift versionsKubernetes version
4.16, 4.16 EUS1.29
4.151.28
4.14, 4.14 EUS1.27
4.131.26
4.12, 4.12 EUS1.25
4.111.24
4.10, 4.10 EUS1.23
4.91.22

Note that some OpenShift versions listed above may be predicted, since an updated version of OpenShift may not yet be available for the latest Kubernetes releases.

The last version of cert-manager to support OpenShift 3 was cert-manager 1.2, which is no longer maintained.

Terminology

The term "release" (or "minor release") refers to one minor version of cert-manager. For example, 1.2 and 1.3 are two releases. Note that we do not use the prefix v for releases (just "1.2"). This is because releases are not used as git tags.

Patch releases use the v prefix (e.g., v1.2.0, v1.3.1...) since one patch release = one git tag. The initial patch release is called "final release":

Type of releaseExample of git tagCorresponding releaseCorresponding release branch*
Final releasev1.3.01.3release-1.3
Patch releasev1.3.11.3release-1.3
Pre-releasev1.4.0-alpha.0N/A**release-1.4

*For maintainers: each release has an associated long-lived branch that we call the “release branch”. For example, release-1.2 is the release branch for release 1.2.

**Pre-releases (e.g., v1.3.0-alpha.0) don't have a corresponding release (e.g., 1.3) since a release only exists after a final release (e.g., v1.3.0) has been created.

Our naming scheme mostly follows Semantic Versioning 2.0.0 with v prepended to git tags and docker images:

v<major>.<minor>.<patch>

where <minor> is increased for each release, and <patch> counts the number of patches for the current <minor> release. A patch is usually a small change relative to the <minor> release.

Old cert-manager releases

These cert-manager releases have reached their EOL date and are no longer supported.

ReleaseRelease DateEOLCompatible Kubernetes versionsCompatible OpenShift versions
1.14Feb 03, 2024Oct 03, 20241.24 → 1.314.11 → 4.16
1.13Sep 12, 2023Jun 05, 20241.21 → 1.274.8 → 4.14
1.11Jan 11, 2023Sep 12, 20231.21 → 1.274.8 → 4.14
1.10Oct 17, 2022May 19, 20231.20 → 1.264.7 → 4.13
1.9Jul 22, 2022Jan 11, 20231.20 → 1.244.7 → 4.11
1.8Apr 05, 2022Oct 17, 20221.19 → 1.244.6 → 4.11
1.7Jan 26, 2021Jul 22, 20221.18 → 1.234.5 → 4.9
1.6Oct 26, 2021Apr 05, 20221.17 → 1.224.4 → 4.9
1.5Aug 11, 2021Jan 26, 20221.16 → 1.224.3 → 4.8
1.4Jun 15, 2021Oct 26, 20211.16 → 1.214.3 → 4.7
1.3Apr 08, 2021Aug 11, 20211.16 → 1.214.3 → 4.7
1.2Feb 10, 2021Jun 15, 20211.16 → 1.214.3 → 4.7
1.1Nov 24, 2020Apr 08, 20211.11 → 1.213.11 → 4.7
1.0Sep 02, 2020Feb 10, 20211.11 → 1.213.11 → 4.7
0.16Jul 23, 2020Nov 24, 20201.11 → 1.213.11 → 4.7
0.15May 06, 2020Sep 02, 20201.11 → 1.213.11 → 4.7
0.14Mar 11, 2020Jul 23, 20201.11 → 1.213.11 → 4.7
0.13Jan 21, 2020May 06, 20201.11 → 1.213.11 → 4.7
0.12Nov 27, 2019Mar 11, 20201.11 → 1.213.11 → 4.7
0.11Oct 10, 2019Jan 21, 20201.9 → 1.213.09 → 4.7