Helm 3 End of Life

Helm 3 is approaching end-of-life. A final, limited Helm 3 feature release will be September 9th, 2026, with security patches continuing to be provided through February 2027.

With the successful release of Helm 4 in November 2025, the maintainers and community are now focused on enhancing the functionality of Helm 4. If you haven't started evaluating Helm 4, now is the time.

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.

Helm 3 End of Life Timeline

The 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 create one extra (limited) feature release on September 9th, 2026 and extend security support to February 10th, 2027 - three months beyond the original timelines.

The Helm 4 development cycle and Helm 3 support timeline was originally documented in HIP-0012: Helm 4 Development Process: Maintaining Helm 3.

The updated timeline is as follows:

• Bug fixes up to the final feature release, September 9th, 2026.
• Final feature 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 other new features will be backported.
• Security fixes end February 10th, 2027 (extended from November 2026).

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.

Why Helm 4

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 from being introduced 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.

For full details, see HIP-0012: Helm 4 Development Process.

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.

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 little to no changes required.

What's New in Helm 4

Here is an overview of the key changes. For full details, see the Helm 4 Overview.

New Features

• 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 for details.
• Better resource monitoring — kstatus integration provides detailed deployment status tracking.
• Multi-document values — Split values across multiple YAML files for environment-specific configurations.
• Server-side apply — Default for new releases, with automatic latching to client-side apply for upgrades of existing Helm 3 releases.
• Custom template functions — Extend Helm's templating through plugins.
• Stable SDK API — API breaking changes are complete, enabling Charts v3 development.

Breaking Changes

• Post-renderers are plugins — helm install --post-renderer now takes a plugin name, not an executable path. Update any existing post-renderer workflows.
• Registry login scoped to domain — helm registry login accepts domain names only (not full URLs), enabling future per-scope login.
• CLI flag renames — --atomic is now --rollback-on-failure and --force is now --force-replace. The old flags still work but emit deprecation warnings.

Improvements

• Faster dependency resolution and content-based chart caching.
• Clearer error messages.
• Better OAuth and token support for private registries.

Helm 3 Security Patch Release

HIP-0012 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 the migration to Helm 4.

During this security-only maintenance window:

• No new features will be backported to Helm 3, including updates to Kubernetes client libraries.
• Only security patches will be released (on demand / as needed).
• No bug fixes will otherwise be applied.

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.

Migrating to Helm 4

The upgrade path is designed to be straightforward. The following steps can be used to make your migration journey as smooth as possible:

1. Test your charts — Deploy your existing charts with Helm 4 in a non-production environment
2. Test your CI/CD pipelines — Update any scripts using renamed CLI flags (--atomic → --rollback-on-failure, --force → --force-replace)
3. Test post-renderer workflows — Migrate any --post-renderer usage to the new plugin system
4. Test registry authentication — Verify OCI workflows with helm registry login using domain names only
5. Upgrade — Helm 4 can manage existing Helm 3 releases without any migration steps
   • 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 latching behavior can be overridden by explicitly setting --server-side=false.

For the full upgrade checklist, see the Upgrading to Helm 4 section of the documentation.

Get Involved

• GitHub Issues: helm/helm
• Kubernetes Slack: #helm-dev and #helm-users
• Weekly Dev Meetings: Thursdays 9:30am PT on Zoom

For more details, see the community communication guide.