Helm 4 is here: Server-Side Apply, WebAssembly Plugins, and the Migration from Helm 3

After six years and over 500 million chart installations, Helm has been released in version 4. The release at KubeCon North America 2025 marks one of the most profound architectural changes in the history of the Kubernetes package manager. Server-Side Apply, a WebAssembly-based plugin system, and more reliable deployment status monitoring make Helm 4 not only more secure but also more powerful for modern GitOps workflows. The following article summarizes the most important innovations and provides guidance for the upcoming migration.

Server-Side Apply: The End of Three-Way Merge

The most significant change in Helm 4 is the switch from the previous three-way merge strategy to Server-Side Apply (SSA). Helm 3 compared three states for this: the desired state from the chart, the live state in the cluster, and the last successful configuration from a secret. Kubernetes itself has relied on SSA since version 1.22 and records there which manager (controller, tool, or user) manages which field of an object.

Helm 4 uses SSA by default for new installations. For upgrades of existing releases, the previous procedure remains – anyone who wants to switch explicitly passes --server-side. A new --force-conflicts flag allows overwriting field conflicts if necessary. Especially in GitOps environments with ArgoCD or Flux, teams benefit from this change: when Helm only updates the fields it manages itself, the previous overwriting conflicts with other controllers are eliminated.

WebAssembly Plugins: Security Through Sandboxing

Helm 3 plugins ran as native binaries with full system access. A malicious plugin could read the kubeconfig or establish arbitrary network connections. Helm 4 introduces an optional WebAssembly runtime that executes plugins in a sandboxed environment. Permissions are explicitly declared: a plugin can, for example, only read access /tmp or only establish HTTPS connections to a specific domain.

The WebAssembly plugins are platform-independent – a .wasm file runs identically on Linux, macOS, and Windows. Existing native plugins continue to work, but the Helm team recommends switching to Wasm for security reasons. An important breaking change concerns post-renderers: these can no longer be passed as an executable file via --post-renderer, but must be registered as a plugin.

Kstatus Watcher and More Reliable Deployments

A long-standing problem in Helm 3 was the unreliable --wait option: Helm marked a deployment as complete as soon as the resources were created – not when they were actually operational. Helm 4 integrates the Kubernetes library kstatus, which precisely interprets the health status of native resources (Deployments, StatefulSets, Services).

With two new annotations — helm.sh/readiness-success and helm.sh/readiness-failure — chart authors can specify when a resource is considered ready. Helm installs the next resource group only when the previous one is actually running. Race conditions, where an application starts before its database, are thus a thing of the past.

OCI Digest Installation and Content-Based Caching

For supply chain security, Helm 4 introduces installation via OCI digest: helm install myapp oci://registry.example.com/charts/app@sha256:abc123.... Charts with a non-matching digest are rejected. At the same time, a content-based cache replaces the old name/version-based cache: two charts with the same name and same version but different content no longer collide. This noticeably speeds up dependency resolution and helm dependency update.

Other Innovations and CLI Changes

Helm 4 brings multi-document values: using the --- YAML separator, multiple YAML documents can be placed in a single values file – useful for complex environment overlays. The new --set-json parameter allows passing structured JSON values without workarounds. Some CLI flags have been renamed: --atomic is now --rollback-on-failure, --force became --force-replace. The old names trigger a deprecation warning and should be replaced in CI/CD pipelines.

Migration Strategy

The Helm team grants a generous transition period: bug fixes for Helm 3 run until July 2026, security fixes until November 2026. New features will no longer be backported. Charts in the current APIv2 format remain fully compatible – no chart changes are necessary. An experimental v3 chart format is already available via the environment variable HELM_EXPERIMENTAL_CHART_V3.

For migration, a staggered approach is recommended: Helm 3 and Helm 4 can coexist as separate binaries on the same system. First, non-production environments should be tested with Helm 4 before the CI/CD pipelines are switched over. Special attention should be paid to plugins and post-renderers – these must be checked for compatibility.

Conclusion

Helm 4 is not a radical break, but a much-needed modernization step. Server-Side Apply ends the era of conflicts between GitOps tools, WebAssembly plugins bring enterprise security to the plugin architecture, and kstatus finally makes deployment status reliable. Anyone operating Kubernetes in production should plan the migration by 2026 – support for Helm 3 is scheduled to expire.

Sources

• Helm 4 Released (Official Blog) — Release announcement at KubeCon NA 2025
• Helm 4: the key improvements! (enix.io) — Detailed analysis of the innovations and migration
• Helm 4: What Actually Changed And How To Migrate From Helm 3 (alexandre-vazquez.com) — Comprehensive migration guide with FAQ
• Helm 4 Overview (Helm Docs) — Official overview with breaking changes and new features