Helm Support Lifecycle & Release History

How Does Helm Handle Version Support?

Helm defines support at the major version level. Within each major line, only the latest minor release receives active maintenance -- bug fixes and security patches are not backported to older minor versions. When a new minor ships, the previous one is superseded immediately.

Helm uses Semantic Versioning (major.minor.patch). Patch releases carry fixes cherry-picked into the current minor branch. The project ships on a fixed cadence -- typically the second Wednesday of each month.

When a new major version is released, the previous major line does not drop support immediately. Instead it enters a phased wind-down: first a period of bug fixes and security patches, then security patches only, then full end of life. The exact dates for each major line are shown in the release table above.

One exception during the transition window: Kubernetes client library updates are backported even after feature freeze, to keep the previous major compatible with newly released Kubernetes versions.

References: Helm Version Skew 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.