Helm 4 Overview | Helm

Helm v4 represents a significant evolution from v3, introducing breaking changes, new architectural patterns, and enhanced functionality while maintaining backwards compatibility for charts.
For more information about the planned Helm 4 release phases, see Path to Helm v4.
This section provides an overview of what's new in Helm 4, including breaking changes, major new features, and other improvements. For complete technical details, see the Full Changelog.
Post-renderers are implemented as plugins. With this change, it is no longer possible to pass an executable directly to helm render --post-renderer, but a plugin name must be passed. This might require updates to any existing post-renderer workflows.
The helm registry login command must be done with the domain name only in v4. This is so login can be scoped at different levels on a registry in the future.
Helm 4 introduces an optional WebAssembly-based runtime for enhanced security and expanded capabilities. Existing plugins continue to work, but the new runtime opens up more of Helm's core behavior for plugin customization. Helm 4 launches with three plugin types: CLI plugins, getter plugins, and post-renderer plugins, plus a system that enables new plugin types for customizing additional core functionality. See HIP-0026 plugin system and Helm 4 example plugins.
If you maintain a Helm 3 plugin, see Migrate v3 Plugins to Helm 4.
Existing plugins work as before. The new WebAssembly runtime is optional but recommended for enhanced security.
New kstatus integration shows detailed status of your deployments. Test with complex applications to see if it catches issues better.
Install charts by digest for better supply chain security. For example, helm install myapp oci://registry.example.com/charts/app@sha256:abc123.... Charts with non-matching digests are not installed.
Split complex values across multiple YAML files. Perfect for testing different environment configs.
Better conflict resolution when multiple tools manage the same resources. Test in environments with operators or other controllers.
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 is done to ensure continuity of operation for existing releases that used client-side apply. The behavior can be overridden by setting the --server-side flag explicitly.
As such, all releases created by Helm 3 will default to using client-side apply after upgrading to Helm 4.
Extend Helm's templating with your own functions through plugins. Great for organization-specific templating needs.
Post-renderers are implemented as plugins, providing better integration and more capabilities.
API breaking changes are now complete. Test it, break it, give us feedback! The API also enables additional chart versions, opening possibilities for new features in the upcoming Charts v3.
Charts v3 is in early development and available for experimentation. v2 charts continue to work unchanged.
Set the HELM_EXPERIMENTAL_CHART_V3 environment variable:
Create a new chart using the v3 API version:
Charts v3 is experimental. Features might change or be removed before the final release. Use for testing and feedback only.
Faster dependency resolution and new content-based chart caching.
Clearer, more helpful error output.
Better OAuth and token support for private registries.
Some common CLI flags are renamed to better clarify their operation. The existing flags remain, but emit a deprecated warning:
Update any automation that uses these renamed CLI flags.
The following flags for helm template are deprecated and will be removed in Helm 5:
These flags have no effect because template output never includes notes. They remain in Helm 4 for backwards compatibility but are hidden from help output.
While we work hard to make Helm 4 rock-solid for everyone, Helm 4 is brand new. To that end, before upgrading, we've added some tips below for specific things to look out for when testing Helm 4 with your existing workflows. As always, we welcome all feedback about what works, what breaks, and what could be better.
Find issues? Have suggestions? We want to hear from you:
Review the list of open issues and feature requests in the Helm repo. Add comments on the existing items, or create new issues and requests.
Join Kubernetes Slack channels:
Join live discussion with maintainers every Thursday 9:30am PT on Zoom.
For more options, see the Helm community communication details.
We are a Cloud Native Computing Foundation graduated project.
© Helm Authors 2026. Documentation distributed under CC-BY-4.0.
© 2026 The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.