Helm v4 vs. v3: Understanding the Key Differences

Helm 4: First Major Update in Six Years

Helm has finally released version 4—its biggest upgrade since Helm 3. In this summary, we’ll examine the notable improvements: the adoption of Server-Side Apply instead of 3-Way Merge, support for WASM-based plugins, a switch to kstatus for readiness checks, and a new content-based chart caching system. We’ll also touch on Helm’s remaining drawbacks and potential solutions.

Server-Side Apply: Replacing 3-Way Merge

Kubernetes introduced Server-Side Apply (SSA) in version 1.14 as a new method for updating resources. Helm 4 now supports SSA, replacing the long-standing 3-Way Merge (3WM) approach, which has historically caused incorrect updates.

Helm’s issue is that it struggles to understand which fields were changed during the previous release. As a result, the old 3WM approach might leave outdated data behind—for example, a field removed from the chart could remain on the cluster.

SSA eliminates this problem. Instead of computing the patch itself, Helm hands off the entire manifest to Kubernetes, which performs the merge and patching automatically.

To enable SSA during an upgrade:

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

Explaining the --force-conflicts flag

You can add another flag to resolve conflicts automatically:

When a conflict occurs, Kubernetes will always favor the manifest rendered by Helm. Since this option is disabled by default, it’s generally recommended to turn it on when using SSA.

WASM Plugin Support

Helm 4 now supports plugins compiled to WebAssembly (WASM), in addition to the traditional Helm 3 plugins. For most users, nothing changes immediately, but plugin authors gain access to a more flexible and powerful API.

WASM plugins can currently be one of three types:

• CLI plugins — behave like existing Helm plugins and receive Helm’s command-line inputs.

• Postrenderer plugins — process rendered templates and return modified YAML (useful for patching manifests before deployment).

• Getter plugins — used when fetching charts; they accept a URI and fetch raw data, enabling custom loaders (Git, S3, etc.).

Documentation is still sparse, though you can find additional technical details in the relevant HIP proposal.

kstatus: Improved Readiness Tracking

Helm 3 offered only basic readiness checks when users enabled --wait, covering Deployments, StatefulSets, Services, and a few others. Helm 4 replaces this simplistic mechanism with kstatus, a Kubernetes readiness evaluation tool.

The change mostly affects accuracy; users will now get more reliable status checks without needing to modify workflows.

To activate the new readiness tracker:

Explaining this option

The watcher mode uses kstatus to monitor resource state during a release. Helm will pause the upgrade until Kubernetes reports that all tracked resources are fully ready.

Content-Based Chart Caching

Historically, Helm cached charts using only their name and version. Since this wasn’t unique enough, Helm often ignored its own cache and re-downloaded charts unnecessarily.

Helm 4 now caches charts based on a hash of their actual contents, allowing Helm to safely reuse previously downloaded charts. This feature doesn’t apply to OCI-stored charts, which remain an exception.

Additional Updates

• New template functions: mustToYaml and mustToJson

• OCI chart installation now supports digests

• Postrenderers can now process hook resources

• Small improvements to the Helm SDK

• values.yaml can now include multiple YAML documents separated by ---

• A new apiVersion: v3 for Chart.yaml — this removes support for requirements.yaml and requirements.lock

A handful of deprecated flags were removed, a few renamed, and validation has been tightened.

Conclusion

Most enhancements in Helm 4 address long-term technical debt: SSA replaces unreliable 3-Way Merge logic, kstatus replaces Helm’s limited readiness engine, and plugin and renderer systems have been modernized.

However, from a user perspective, only SSA truly changes day-to-day workflows. Helm still lacks reliable CRD handling, deployment order control, and management for immutable resources—issues that force many users to rely on hooks and external plugins.

For those interested in more details, the Major Changes Summary provides a compact overview, and the full changelog offers an exhaustive breakdown of Helm 4 modifications.