Helm 4: the key improvements!

Helm 4 was released as planned in late 2025 during KubeCon + CloudNativeCon North America. We had anticipated 1 year ago the main new features in this article — here’s what the final release confirms and clarifies.

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 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 now uses Server Side Apply (SSA) by default, but only for new installations. For upgrades and rollbacks, Helm retains the method used during the initial installation: all your existing releases created with Helm 3 will therefore continue to use client-side apply after migrating to Helm 4. You will need to explicitly pass the --server-side flag to force the switch for an existing release.

When a conflict occurs - e.g. when different owners modify the same field - Helm 4 will generate an explicit error rather than overriding everything with a patch. Conflicts can still happen… but this time, the user is clearly notified!

Notably, Helm 4 introduces—similar to kubectl—a --force-conflicts=false|true flag (defaulting to false) for the install, upgrade, and rollback commands, allowing conflicts to be overridden when necessary.

Also worth noting: the --force flag has been renamed to --force-replace. The old name still works but now emits a deprecation warning—make sure to update your automation scripts.

However, Helm 4 does 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 is not supported

Backward compatibility with charts deployed using three-way merge is 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 is now 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 waits until each component is truly operational. Users 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 relies now on a hash of the chart content to determine whether it should download the content or not.

• A full plugin system overhaul using Wasm: Helm 4 introduces an optional runtime based on WebAssembly, with three types of official plugins—CLI, getter, and post-renderer. Existing plugins continue to work without modification. However, there is an important breaking change: post-renderers can no longer be passed as an arbitrary executable via --post-renderer. You must now provide a plugin name instead. If you are using post-renderers in your CI/CD pipelines, some adjustments will be required.

• Warning for non-SemVer chart versions: helm lint now emits a warning if the chart version in Chart.yaml is not expressed as a valid SemVer 2. The helm package command does not fail, however—this is a preventive alert rather than a blocking issue.

• Another feature we hadn’t initially mentioned is support for multi-document values files: until now, a Helm values file could only contain a single YAML document. Helm 4 now allows the use of the --- separator within the same values file, making it possible to include multiple distinct YAML documents.

In practice, this makes managing complex configurations easier: you can logically structure a very dense values file, or group values for different contexts into a single file, without having to multiply -f flags in your Helm commands.

Helm 4: official release and migration

No need to worry about backward compatibility: the Helm teams have clearly anticipated the challenges of migrating to Helm 4.

Existing charts (v2, i.e., those from Helm 3) continue to work without any modification. A new v3 chart format is planned, but it is not yet available in Helm 4.0—the official documentation lists it as “coming soon” for 2026 (and yes… the numbering can be confusing, but we are indeed talking about chart version 3 for Helm 4).

At the time of updating this article, the latest release is version 4.1.3, which includes an initial set of fixes. For a more comprehensive overview of the changes introduced in Helm 4, feel free to check out the team’s full changelog.

Do not miss our latest DevOps and Cloud Native blogposts! Follow Enix on Linkedin!