Helm 3 end of life, explained

Helm 3's end of life is the date after which the Helm project stops shipping any Helm 3 release, security fixes included. That date is February 10, 2027, according to the Helm project's end-of-life post. Many guides still give November 2026, the date in the original plan. Teams that run Helm 3 in scripts and pipelines have about three months left to move to Helm 4.

Helm is the package manager for Kubernetes, the system that runs containers across many servers. A Helm chart is a package of templates for one app. Installing a chart creates a release, and every upgrade adds a numbered revision to that release's history.

This guide covers the schedule, what Helm 4 changes, and a hands-on test of Helm 4.3.1 on releases made by Helm 3.22.1.

How Helm 3's end of life works

Helm 3 is being wound down in two steps, according to the end-of-life post George Jenkins wrote for the project on June 2, 2026.

• Bug fixes ended on September 9, 2026. That day's release was the last Helm 3 feature release. It only added updated Kubernetes client libraries, so Helm 3 could talk to newer Kubernetes versions.
• Security fixes end on February 10, 2027. If a flaw is found before then, the project still ships a patch. After that date, the post says Helm 3 gets no more updates, "including Kubernetes client library and security patches."

The v3.22.0 release notes confirm that 3.22 is the last Helm 3 minor version. The newest patch, 3.22.1, came out on October 15, 2026.

End of life does not switch anything off. A Helm 3 binary keeps running after February 10, 2027, as Private DevOps points out in its migration guide. It just stops receiving security fixes and support for new Kubernetes versions.

What changed and when

The original timeline came from HIP-0012, a Helm improvement proposal. It promised Helm 3 security fixes for one year after Helm 4.0.0, which meant November 2026. In June the maintainers added three months.

Date	What happened
November 12, 2025	Helm 4.0.0 released at KubeCon, the first new major Helm version in six years
June 2, 2026	Helm extends Helm 3 security fixes by three months
September 9, 2026	Last Helm 3 feature release (3.22); bug fixes end
October 15, 2026	Helm 3.22.1 and Helm 4.3.1 released, the newest versions as of November 8
January 13, 2027	Helm 4.4.0 scheduled, per the release page
February 10, 2027	Helm 3 security fixes end; no further Helm 3 releases

The post's advice is direct: "We strongly encourage all users to migrate to Helm 4 before that date."

What Helm 4 changes for Helm 3 users

The Helm project says Helm 4 "is expected to be compatible with the majority of existing Helm 3 charts, releases, and workflows." Charts in today's v2 format work unchanged, and a new v3 chart format is still experimental. The Helm 4 overview lists the changes that do matter:

• Renamed flags. --atomic is now --rollback-on-failure, and --force is now --force-replace. The old names still work but print a warning.
• Post-renderers are plugins. A post-renderer edits Helm's output before it reaches the cluster. --post-renderer now takes the name of an installed plugin, not the path to a script.
• Registry login takes a host name. helm registry login accepts a domain only, not a URL.
• Server-side apply for new installs. With server-side apply, Kubernetes itself merges each change and records which tool owns each field. Upgrades and rollbacks keep the method a release already used, so releases made by Helm 3 stay on the older client-side method. The --server-side flag overrides this.
• A new plugin system. Existing plugins keep working. Plugins can also run on an optional WebAssembly runtime, which the project recommends for security.

Tested: Helm 4.3.1 on releases made by Helm 3

In a Tech AI Wire test on November 8, 2026, a k3s cluster running Kubernetes 1.36.6 ran in Docker 28.4.0 on macOS 26.6.2. Both Helm binaries came from get.helm.sh, and their SHA-256 checksums matched. Helm 3.22.1 installed the sample chart that helm create writes. Helm 4.3.1 then worked on the same release. The two binaries are called helm3 and helm4 below.

helm3 install web ./demo --wait
helm4 upgrade web ./demo --atomic --set replicaCount=2
helm4 registry login https://ghcr.io -u test -p test
helm4 template web ./demo --post-renderer ./pr.sh
helm4 get metadata web

Test	Result
Helm 4 reads the Helm 3 release	Yes: helm list and helm history showed it
upgrade --atomic	Worked, with "Flag --atomic has been deprecated, use --rollback-on-failure instead"
upgrade --force	Worked, with "Flag --force has been deprecated, use --force-replace instead"
registry login https://ghcr.io	Failed: invalid reference: invalid registry "https://ghcr.io"
--post-renderer ./pr.sh, a shell script	Failed: plugin not found; Helm 3.22.1 ran the same script
Apply method of the Helm 3 release after Helm 4 upgrades	"client-side apply (defaulted)"
Apply method of a new Helm 4 install	"server-side apply"
Helm 3 after the Helm 4 upgrades	Read all four revisions and rolled back to revision 1

Kubernetes' own records agreed. The Helm 3 release's deployment was written with an "Update" operation, and the new Helm 4 release with an "Apply".

One result is not in the docs. --server-side=true moved the Helm 3 release to server-side apply. A later upgrade with Helm 3.22.1 then made Helm 4 report it as client-side apply again, marked "(defaulted)". Old and new binaries taking turns on one release can quietly undo a migration.

What this means for developers

• Fix the two hard failures first. Search CI scripts for helm registry login with https:// and for --post-renderer pointing at a script. Both stop a Helm 4 pipeline, while the renamed flags only print warnings.
• Rename --atomic and --force now. They still work, but Helm 4 marks them as deprecated and prints a warning on every run.
• Pick one binary per release. During the move, let only Helm 4 upgrade a release once it has touched it, or the apply method can flip back.
• Decide on server-side apply on purpose. Releases made by Helm 3 stay client-side until someone passes --server-side. Try the switch on a staging cluster before production.
• Pin the Helm version in CI and test rollbacks. Private DevOps suggests listing every Helm call and staging Helm 4 outside production first.
• Do not wait for February 10. After that date, a Helm 3 security flaw stays unpatched, and newer Kubernetes versions get no Helm 3 client support.