Helm v4: key changes from v3

Ilya Lesikov — Mon, 17 Nov 2025 16:04:31 +0000

Helm's first major release in six years, v4, is now available. In this article, I'll explore the key changes: switching from 3-Way Merge to Server-Side Apply, support for WASM plugins, improved resource readiness tracking, content-based chart caching, and more.

Server-Side Apply instead of 3-Way Merge

Server-Side Apply (SSA) is the resource update mechanism introduced in Kubernetes 1.14. Using SSA instead of 3-Way Merge (3WM) can help to avoid incorrect resource updates that sometimes occur with Helm.

Helm cannot determine which resources were updated in a previous release and which were not. Because of this, 3WM might miss removing a field that is no longer present in a chart, for example.

SSA addresses such issues by eliminating the need for Helm to compute patches for resource updates. Instead, Helm can now send the entire manifest to the Kubernetes API, where Kubernetes itself computes and applies patches. To enable SSA, use the --server-side=true flag:

helm upgrade --server-side=true ...

The --force-conflicts flag enables automatic conflict resolution for SSA. With it, the rendered version of the manifest is always preferred. This mode is disabled by default, so we recommend enabling it.

WASM plugins

In addition to the existing Helm 3 plugins, Helm 4 now supports WASM plugins. While this change has minimal impact on end users, it provides plugin developers with a more powerful API.

There are three types of plugins: cli, postrenderer, and getter:

cli plugins work just like Helm 3 plugins. The command that implements the plugin is executed, while command-line arguments from Helm are passed to this command.
postrenderer plugins are executed right after templating of manifests. They take templated manifests as input and are expected to return them as output. For example, they can be used for patching resources before the deployment.
getter plugins run when charts or subcharts are being pulled. They take a URI and connection settings as input and return binary data. They can be used to handle chart pulls from sources such as Git or S3.

There is no proper documentation for WASM plugins yet, but you can find more details in the HIP.

Using kstatus for resource tracking

Helm 3 featured several basic readiness checks for Deployments, StatefulSets, Services, and some other Kubernetes resources. These checks were activated with the --wait flag, so that the release would wait until the resources were ready.

Since resource tracking has never been a primary focus for Helm, the replacement of its tracking engine with kstatus is not surprising. For users, the only noticeable change is that resource readiness checks will be slightly more accurate.

You can enable kstatus for all resources (and not just hooks) with the --wait=watcher flag:

helm upgrade --wait=watcher ...

Content-based chart caching

In Helm 3, downloaded charts were cached based on their name and version. However, this was not enough to uniquely identify them, meaning Helm would end up re-downloading charts all the time because it didn't trust its own cache.

In Helm 4, charts are uniquely identified by the hash sum of their content, so they can be reliably retrieved from the cache. Unfortunately, the new cache currently doesn’t work for OCI charts.

Other changes

New templating functions: mustToYaml and mustToJson.
OCI charts can be installed by their digest.
Post-renderers now work for hooks, not only non-hook resources.
The Helm SDK is improved a bit.
values.yaml files can now include multiple YAML sections separated by ---.
There's new apiVersion: v3 available for Chart.yaml. For now, v3 simply drops support for requirements.yaml and requirements.lock, and does nothing else.
Validation has been improved. A few insignificant flags were added, and a few were renamed or removed.

Conclusion

The majority of changes in Helm 4 focus on reducing technical debt: replacing 3-Way Merge with Server-Side Apply, ditching their custom resource tracking in favour of kstatus, and refactoring postrenderers and legacy plugins.

The biggest change for the end user is fixing 3-Way-Merge-related issues by introducing SSA. However, Helm still lacks proper CRD management, users have to deploy half of their resources as hooks to control their deployment order or to update immutable resources, and numerous years-old bugs (with whole plugins developed to work around them) migrate from one major release to another.

On a related note, Nelm has:

3-Way Merge replaced with SSA years ago, and even built-in nelm release plan works through SSA, unlike helm-diff plugin;
resource tracking miles ahead of kstatus, with heuristic detection of readiness for Custom Resources, displaying current resource statuses, errors, logs, and events during the deployment, and more;
fixed all mentioned issues, such as flawed CRD management, and inflexible deployment ordering.

For those, who are curious, that's how the resource tracking in Nelm looks like.

P.S. For more details on what's new in Helm 4, check out the major changes summary. Even more details are available in the full changelog.