|
| 1 | +--- |
| 2 | +title: "Helm 3 End of Life" |
| 3 | +slug: "helm-v3-end-of-life" |
| 4 | +authors: ["georgejenkins"] |
| 5 | +date: "2026-06-02" |
| 6 | +--- |
| 7 | + |
| 8 | +Helm 3 is approaching end-of-life. The final Helm 3 feature release will be **September 9th, 2026**, with security patches through February 2027. |
| 9 | + |
| 10 | +With the successful release of Helm 4 November, 2025, the maintainers and community are now focused on Helm 4. If you haven't started evaluating Helm 4, now is the time. |
| 11 | + |
| 12 | +Helm 4 offers several improvements over Helm 3 (detailed below), and is expected to be compatible with the majority of existing Helm 3 charts, releases and workflows. |
| 13 | + |
| 14 | +<!-- truncate --> |
| 15 | + |
| 16 | +## Helm 3 End of Life Timeline |
| 17 | + |
| 18 | +The [Helm 4 Released](/blog/helm-4-released) announcement outlined the original Helm 3 support schedule following the Helm 4.0.0 release in November 2025. However, the Helm maintainers have **decided to extend the support to September 2026**, three months beyond the original timeline. |
| 19 | + |
| 20 | +The Helm 4 development cycle and Helm 3 support timeline was riginally documented in [HIP-0012: Helm 4 Development Process: Maintaining Helm 3](https://github.com/helm/community/blob/main/hips/hip-0012.md#Maintaining Helm 3). |
| 21 | + |
| 22 | +The updated timeline is: |
| 23 | + |
| 24 | +- **Bug fixes** ended July 8th, 2026. |
| 25 | +- **Final minor release**: September 9th, 2026 — this will be the last Helm 3 minor release, limited to Kubernetes client library updates for new Kubernetes version support. No new features will be backported. |
| 26 | +- **Security fixes** end February 10th, 2027 (extended from November 2026). |
| 27 | + |
| 28 | +After February 2027, Helm 3 will no longer receive any updates: *including Kubernetes client library and security patches*. We strongly encourage all users to migrate to Helm 4 before that date. |
| 29 | + |
| 30 | +## Why Helm 4 |
| 31 | + |
| 32 | +Helm 3 served the Kubernetes community well for over six years. During that time, the project accumulated technical debt and hit architectural limits that prevented new features without breaking the SDK's public APIs. Helm 4 addresses this with breaking changes that enable the project to move forward, while maintaining significant backwards compatibility with the majority of existing workflows. |
| 33 | + |
| 34 | +For full detailed, see the described in [HIP-0012 (Helm 4 Development Process)](https://github.com/helm/community/blob/main/hips/hip-0012.md): |
| 35 | + |
| 36 | +> Charts deployable with Helm 3 should be deployable by Helm 4. Similarly, any existing chart (release) managed by Helm 3 generally should be upgradable by Helm 4. |
| 37 | +
|
| 38 | +This means you can upgrade the Helm binary without rewriting your charts or redeploying your releases. CLI workflows are also largely preserved - most users should experience no disruption or minimal adjustments. |
| 39 | + |
| 40 | +## What's New in Helm 4 |
| 41 | + |
| 42 | +Here is an overview of the key changes. For full details, see the [Helm 4 Overview](/docs/overview). |
| 43 | + |
| 44 | +### New Features |
| 45 | + |
| 46 | +- **Plugin system overhaul** — An optional WebAssembly-based plugin runtime with enhanced security. Existing plugins continue to work. Three plugin types ship with Helm 4: CLI, getter, and post-renderer plugins, plus an extensible system for new plugin types. See [HIP-0026](https://github.com/helm/community/blob/main/hips/hip-0026.md) for details. |
| 47 | +- **Better resource monitoring** — kstatus integration provides detailed deployment status tracking. |
| 48 | +- **Enhanced OCI support** — Install charts by digest (e.g., `helm install myapp oci://registry.example.com/charts/app@sha256:abc123...`) for supply chain security. |
| 49 | +- **Multi-document values** — Split values across multiple YAML files for environment-specific configurations. |
| 50 | +- **Server-side apply** — Default for new releases, with automatic latching to client-side apply for upgrades of existing Helm 3 releases. |
| 51 | +- **Custom template functions** — Extend Helm's templating through plugins. |
| 52 | +- **Stable SDK API** — API breaking changes are complete, enabling Charts v3 development. |
| 53 | + |
| 54 | +### Breaking Changes |
| 55 | + |
| 56 | +- **Post-renderers are plugins** — `helm install --post-renderer` now takes a plugin name, not an executable path. Update any existing post-renderer workflows. |
| 57 | +- **Registry login scoped to domain** — `helm registry login` accepts domain names only (not full URLs), enabling future per-scope login. |
| 58 | +- **CLI flag renames** — `--atomic` is now `--rollback-on-failure` and `--force` is now `--force-replace`. The old flags still work but emit deprecation warnings. |
| 59 | + |
| 60 | +### Improvements |
| 61 | + |
| 62 | +- Faster dependency resolution and content-based chart caching. |
| 63 | +- Clearer error messages. |
| 64 | +- Better OAuth and token support for private registries. |
| 65 | + |
| 66 | +## Helm 3 Security Patch Release |
| 67 | + |
| 68 | +[HIP-0012](https://github.com/helm/community/blob/main/hips/hip-0012.md) originally specified security fixes for one year from the Helm 4.0.0 release — through November 2026. The Helm maintainers are extending this by three months to **February 10th, 2027**, giving the community more time to complete migrations to Helm 4. |
| 69 | + |
| 70 | +During this security-only maintenance window: |
| 71 | + |
| 72 | +- **No new features** will be backported to Helm 3. Including updates to Kubernetes client libraries |
| 73 | +- **No bug fixes** will be applied (bug fix support will end September 2026) |
| 74 | +- **Only security patches** will be released (on demand / as needed) |
| 75 | +- The September 9th, 2026 final minor release will include Kubernetes client library updates for new Kubernetes version support |
| 76 | + |
| 77 | +If a security vulnerability is discovered in Helm 3 before February 2027, a patch release will be issued. After February 10th, 2027, no further Helm 3 releases of any kind will be made |
| 78 | + |
| 79 | +## Migrating to Helm 4 |
| 80 | + |
| 81 | +The upgrade path is designed to be straightforward: |
| 82 | + |
| 83 | +1. **Test your charts** — Deploy your existing charts with Helm 4 in a non-production environment |
| 84 | +2. **Test your CI/CD pipelines** — Update any scripts using renamed CLI flags (`--atomic` -> `--rollback-on-failure`, `--force` -> `--force-replace`) |
| 85 | +3. **Test post-renderer workflows** — Migrate any `--post-renderer` usage to the new plugin system |
| 86 | +4. **Test registry authentication** — Verify OCI workflows with `helm registry login` using domain names only |
| 87 | +5. **Upgrade** — Helm 4 can manage existing Helm 3 releases without any migration steps |
| 88 | + - To note: Helm 4 will default to server-side apply when installing a new Chart release. When upgrading (or rolling back), Helm will by default follow the previous apply method of the release. This lattching behaviour can be overridden by explicitly setting `--server-side=false` |
| 89 | + |
| 90 | +For the full upgrade checklist, see the [Upgrading to Helm 4](/docs/overview#upgrading-to-helm-4) section of the documentation. |
| 91 | + |
| 92 | +## Get Involved |
| 93 | + |
| 94 | +- **GitHub Issues**: [helm/helm](https://github.com/helm/helm/issues) |
| 95 | +- **Kubernetes Slack**: [#helm-dev](https://kubernetes.slack.com/archives/C51E88VDG) and [#helm-users](https://kubernetes.slack.com/archives/C0NH30761) |
| 96 | +- **Weekly Dev Meetings**: Thursdays 9:30am PT on [Zoom](https://zoom.us/j/696660622?pwd=MGsraXZ1UkVlTkJLc1B5U05KN053QT09) |
| 97 | + |
| 98 | +For more details, see the [community communication guide](https://github.com/helm/community/blob/main/communication.md). |
0 commit comments