Helm Release History & EOL Status

How Does Helm Handle Version Support?

Helm follows a rolling support model: only the most recent minor release receives active maintenance. There is no long-term support (LTS) track and no parallel maintenance of multiple minor versions at the same time. When a new minor version ships, the previous one is effectively in wind-down mode.

Helm uses Semantic Versioning (x.y.z). Patch releases carry bug fixes and security patches cherry-picked from the main branch. The project ships updates on a fixed cadence -- typically the second Wednesday of each month.

When a new major version is released, the previous major line enters a transition period with a phased support schedule, as shown in the release table above. During this window, only critical bug fixes and security patches are backported -- no new features, with the sole exception of Kubernetes client library updates that unlock support for newer Kubernetes versions.

References: Helm Version Support Policy -- Helm Release Policy

What Can Go Wrong When You Run an Unsupported Helm Version?

Helm is a client tool that talks directly to the Kubernetes API server. When your Helm version falls out of support, the most immediate risk is Kubernetes API incompatibility. Kubernetes deprecates and removes API versions on a regular schedule. An unsupported Helm release will not receive the client library updates needed to speak to newer Kubernetes clusters -- meaning upgrades to your cluster can silently break your release workflow.

In practice, teams often discover this the hard way: a cluster upgrade goes through fine, but helm upgrade starts returning cryptic API errors against resources that used deprecated apiVersions in existing chart manifests. Helm cannot auto-migrate those for you.

Beyond compatibility, unsupported versions stop receiving CVE patches. Helm handles Kubernetes credentials and can render templates from third-party charts. A known vulnerability in the template engine or credential handling is a realistic attack surface, especially in shared CI/CD environments where multiple teams push chart deployments.

What Actually Happens After Helm Support Ends?

Helm itself keeps running -- it does not phone home or enforce a version check. But the ecosystem moves on without it. Once a major version hits end of life, the GitHub release branch is closed, the changelog goes quiet, and the community focus shifts entirely to the current major line.

The practical consequence is a slow drift. Community-maintained charts on Artifact Hub begin using new Helm features -- lookup function improvements, new chart schema validations, updated OCI registry support. If your Helm binary is EOL, you will start seeing errors or silently skipped features when installing charts that were tested against the current stable version.

Plugin compatibility is another friction point. Many CI plugins, GitOps operators (like Flux and ArgoCD), and security scanning tools pin their Helm client dependency. EOL Helm versions can fall out of the tested matrix of those tools, and bugs you encounter will get closed as "upgrade first."

In short: nothing breaks on day one of EOL, but the maintenance burden shifts entirely to you. You are responsible for patching, testing, and staying compatible with a Kubernetes version that is also moving forward.

How Do You Check Which Helm Version You Are Running?

Run the following command in any terminal where Helm is installed:

helm version

This prints the full build metadata including the version tag, Git commit, and Go runtime. Example output:

version.BuildInfo{
  Version:"v3.x.x",
  GitCommit:"...",
  GitTreeState:"clean",
  GoVersion:"go1.x.x"
}

For a shorter, script-friendly output:

helm version --short

To check the version from inside a CI pipeline or container, the same command works as long as the Helm binary is on $PATH. Cross-reference the output against the release table above to determine whether your version is still within its active support window or security-only period.

If you manage multiple clusters with different Kubernetes versions, also verify version skew compatibility. Helm supports n-3 minor Kubernetes versions relative to the version it was compiled against. Run:

helm version --short && kubectl version --short

Both versions should fall within the supported skew shown in the official Helm Version Support Policy.