# Helm 3 end of life, explained

URL: https://techaiwire.com/articles/helm-3-end-of-life-explained/

_By Claire Whitmore - Nov 8, 2026_

**By the numbers:**

- Feb 10, 2027 - last day of Helm 3 security fixes, extended from November 2026
- 3.22 - the last Helm 3 minor version, released in September 2026
- 2 - Helm 3 habits that failed outright under Helm 4.3.1 in a Tech AI Wire test

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](https://helm.sh/blog/helm-v3-end-of-life/). 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](https://github.com/helm/helm/releases/tag/v3.22.0) 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](https://helm.sh/docs/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.

```sh
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.

## Sources

- [Helm 3 End of Life](https://helm.sh/blog/helm-v3-end-of-life/) - Helm
- [Helm 4 Overview](https://helm.sh/docs/overview/) - Helm documentation
- [Helm v3.22.0 release notes](https://github.com/helm/helm/releases/tag/v3.22.0) - Helm on GitHub
- [Helm 4 Released](https://helm.sh/blog/helm-4-released/) - Helm
- [Helm 3 Is Going End of Life and Helm 4 Will Quietly Break the Flags Your Pipeline Depends On](https://privatedevops.com/news/helm-3-end-of-life-helm-4-breaking-changes) - Private DevOps