Helm 4 is arriving in just a few days, bringing a set of new features highly anticipated by the Kubernetes community. So we thought a bit of exploration into the upcoming changes could be useful for all of us!
We took a deep dive into the main new features of Helm 4 — from the shift to Server Side Apply to the advanced management of resource status. The goal: to better understand what these changes mean for your Kubernetes deployments, and how to anticipate the migration to Helm 4.
The team behind Helm has already published a summary of what’s new in version 4. Here, we focus on the changes that we believe are the most impactful and useful.
Helm 4: the end of the three-way merge
Helm 4 ends the three-way merge method in favor of Server Side Apply. Let’s take a closer look…
The three-way merge, a quick reminder
The three-way merge is the process Helm 3 currently uses to handle concurrency issues when modifying an object. To do so, it compares three states:
- The new state defined in the manifest you want to apply
- The current state of the object (the “live” state)
- And the last successfully applied configuration, stored in a secret (the one you see with
helm history)
But this method — which also used to be the approach of the Kubernetes API — has not been used by Kubernetes itself for several years. It was therefore time for Helm to align. Catching up on technical debt has been one of the stated objectives of Helm 4 since the beginning of the project!
The solution: Server Side Apply (SSA)
Helm 4 implements a more declarative approach, already standard in Kubernetes since version 1.22: Server Side Apply.
Each modification to a field of an object is assigned an owner. You can inspect the owners of each field using kubectl get with the --show-managed-fields flag.
Helm 4 intends to use Server Side Apply (SSA) by default, although the three-way merge method should remain available for a while behind a flag if needed. When a conflict occurs — when different owners modify the same field — Helm 4 should generate an explicit error rather than overriding everything with a patch. Conflicts can still happen… but this time, the user will be clearly notified!
Helm 4 is also expected to include, like kubectl, a --force-conflicts=false|true flag (defaulting to false) for the install, upgrade and rollback commands, to override conflicts if necessary. However, Helm 4 will not support two cases:
- multiple owners for a single Helm manifest: initially, there can only be one owner per manifest
- ownership transfer of a field: unlike Kubernetes, field ownership transfer will not be supported
Backward compatibility with charts deployed using three-way merge should be ensured — unless your cluster is running Kubernetes < 1.22… which seems unlikely!
Helm 4: more reliable deployments
When “ready” doesn’t quite mean ready (our good old helm install --wait)
Currently, with helm install --wait, Helm mainly waits for Deployments and a few other resource types to be ready. But ready does not necessarily mean the deployed application is actually initialized and functional.
Helm currently has no native mechanism — for users or chart maintainers — to wait for a precise condition before proceeding with the deployment of a resource, except for workarounds such as hooks or init containers.
This becomes especially problematic when deploying an application that depends on a database managed by a chart or subchart.
With Helm 4, using status as the source of truth
The solution: kstatus. It’s a standard Kubernetes library that can interpret the health status of many native Kubernetes resources (Deployments, StatefulSets, Services, etc.) far more accurately than the current helm --wait.
It will now be possible to control deployments with much greater granularity. With two new annotations — helm.sh/readiness-success and helm.sh/readiness-failure — Helm will continue deploying the next resource group or subcharts only once the status has the expected value.
With this improvement, no more deployments failing because of race conditions (e.g., an application starting before its database). Helm will wait until each component is truly operational. Users will have near-total control over what “success” or “failure” means at each stage of their deployment.
Other notable Helm 4 features
Helm 4 brings many other improvements and new capabilities. The following seem most notable:
-
A smarter caching system: Helm’s cache has so far been based on chart name and version, meaning that two different charts (one with a Deployment, the other with a StatefulSet) sharing the same name and version would collide. For this reason Helm ignored the cache and always downloaded the content. Helm 4 will instead rely on a hash of the chart content to determine whether it should download the content or not.
-
A full plugin system overhaul using Wasm: better plugin security, with backward compatibility for legacy plugins.
-
Failure for non-SemVer chart versions:
helm packagewill fail if the chart’s version in Chart.yaml is not a valid SemVer 2 version (still a prospective feature).
Helm 4: official release and migration
No worries on the compatibility front: the Helm team seems to have anticipated the challenges of Helm 4 migration. Helm 3 charts will remain compatible, and Helm 4 will support the new chart formats (v3) while maintaining compatibility with older ones (v2). (Yes… the versioning is a bit confusing: chart version 3 for Helm 4.)
For the eager ones, the beta version is already available. For everyone else, the official Helm 4 release date is expected around November 10–13 at KubeCon + CloudNativeCon North America 2025. Helm 4 should also be a major topic at the upcoming Cloud Native Days France, which we are helping organize, as we did for KCD France in 2023. We hope to see you there!
This blog post will be updated when v4 is officially published, and we’ll add practical feedback on migrating to Helm 4 for production applications on Kubernetes clusters.
Do not miss our latest DevOps and Cloud Native blogposts! Follow Enix on Linkedin!