Helm 4: what changed

Helm 3 came out in 2019. That's ancient history in Kubernetes years. It removed Tiller, the server-side component everyone hated, and then stayed remarkably stable for six years. Millions of deployments depend on it.

Helm 4 came out in late 2025, announced at KubeCon North America. So the big question for most teams: what's different, and do I need to change anything?

What's new

Helm 4 is less of a revolution than Helm 3 was. It's more of a modernisation. The headline changes:

Server-side apply. Helm 3 applied resources with its own three-way merge logic on the client. Helm 4 can use Kubernetes' server-side apply, which is how modern tools like Argo CD and Flux increasingly work. This makes Helm play nicer with other tools touching the same resources, and handles field ownership properly.

Better waiting and status checks. The --wait behaviour has been reworked to use more modern status checking, so Helm has a better understanding of whether resources are actually ready, including custom resources.

A new plugin system. Plugins can now be written as WebAssembly modules, which makes them portable and sandboxed instead of arbitrary scripts running on your machine. Old-style plugins still work.

OCI registries are first class. Storing charts in container registries (like Docker Hub, GHCR, ECR, Harbor) was already possible in Helm 3. In Helm 4, OCI is the clear default direction, and the old index.yaml style chart repositories feel increasingly like legacy.

Modernised internals and SDK. Structured logging, cleaned-up Go APIs, and lots of internal refactoring. This matters mostly to tools built on top of Helm's libraries.

Do my old charts still work?

This is the most important question, and the good news: yes, existing charts (apiVersion v2) keep working in Helm 4. The maintainers were careful about compatibility. Release history from Helm 3 is also understood by Helm 4, so you can upgrade the CLI and keep managing your existing releases.

Where you might notice differences:

• Some command-line flags were renamed or removed. Scripts and CI pipelines that call Helm directly should be tested.
• Server-side apply can surface field ownership conflicts that the old client-side logic silently overwrote.
• Tools that embed Helm as a library (some CI tools, older operators) may need updates for the new SDK.

My suggestion: run Helm 4 in a test pipeline against your charts and environments first. Check helm template, helm upgrade --dry-run, and a real upgrade on a non-production cluster.

Helm 4 doesn't ask you to rewrite your charts. It asks you to re-test your pipelines, which you should be doing anyway.

Chart habits worth keeping

A major version is a good excuse to clean up your charts:

• Add a values.schema.json so wrong values fail fast with a clear error instead of a broken deployment.
• Write chart tests (helm test) and run helm lint in CI.
• Use library charts for shared templates instead of copying helpers between charts.
• Publish to an OCI registry and sign charts, for example with Cosign.
• Keep values files small with sensible defaults in the chart.
• Pin chart versions in your deployments. Never deploy "latest".

Helm, Kustomize, or something else?

Helm remains the most common way to package Kubernetes applications, especially third-party ones. Almost every open-source project ships a Helm chart.

• Kustomize is great for your own applications when you want plain YAML with overlays per environment and no templating language.
• Kro, Timoni and CUE-based tools offer more structured approaches, but with much smaller ecosystems.
• Many teams use both Helm and Kustomize: Helm for third-party software, Kustomize for their own apps, often managed by Argo CD or Flux.

Should you upgrade?

Yes, but without hurry. Helm 3 continues to receive security fixes for a while, so you have time. Upgrade the CLI in CI first, test your charts, then roll it out to people's machines.

My take: Helm 4 is a quiet upgrade with good foundations. Test your pipelines, clean up your charts, and enjoy not rewriting anything.

— Desly