Helm 4 Migration Guide: What's New and How to Upgrade

Helm 3 landed in 2019 and then stayed remarkably stable for six years — long enough that a lot of teams stopped thinking about the Helm binary as something that could change under them. That era is over. On Wednesday November 12th, 2025, during the Helm 4 presentation at KubeCon plus CloudNativeCon North America, the maintainers cut Helm v4.0.0, and the official announcement went up on the Helm blog five days later.

I run Helm across a handful of clusters, so I read the release notes the same way I read a database major version bump: assume something I depend on moved. The good news is that charts are backward compatible, so your templates keep working. The changes that actually bite are in the CLI flags, the apply strategy, and how plugins and post-renderers are wired. This guide walks through what changed and the exact steps I follow to migrate.

The first major Helm release in six years

Helm turned ten in October 2025, and Helm 4 is the milestone that came with the anniversary. Because it is a full major version, the maintainers were free to make backward-incompatible changes — the release notes say plainly that Helm v4 changes the flags and output of the CLI as well as the Go SDK. That is the mental model to hold: charts are safe, tooling is not automatically safe.

The upgrade is also happening on a clock. Helm 3 will keep getting bug fixes only up to its final feature release on September 9th, 2026, and security fixes end on February 10th, 2027 — extended from an earlier November 2026 date. After that, Helm 3 stops receiving any updates at all, including Kubernetes client library and security patches. There is a real window to plan the move rather than rush it.

What is actually new in Helm 4

The release notes group the headline changes into a short list. These are the features I care about as an operator, quoted from the official Helm 4 announcement:

• A redesigned plugin system that supports WebAssembly-based plugins alongside the existing subprocess plugins.
• Post-renderers are now plugins rather than arbitrary executables passed on the command line.
• Server-side apply is now supported, and it becomes the default for freshly installed releases.
• Improved resource watching, so waiting on resources is based on kstatus instead of ad-hoc readiness checks.
• Local content-based caching, for example for charts, to speed up repeated operations.
• Logging via slog, so SDK logging integrates cleanly with modern structured loggers.
• Reproducible, idempotent builds of chart archives, which makes packaging deterministic.
• An updated SDK API, including support for multiple chart API versions from one codebase.

The breaking changes that matter

Most migration pain concentrates in a few CLI details. The registry login command now takes the domain name only — no scheme and no path — so that logins can be scoped at different levels of a registry in the future. Two familiar upgrade flags were renamed: atomic became rollback-on-failure, and force became force-replace. The old names still work in v4 but print a deprecation warning, so scripts keep running while you fix them. And because post-renderers are plugins now, you pass a plugin name instead of an executable path.

# registry login now takes the domain only (no scheme, no path) in Helm 4
helm registry login registry.example.com

# renamed upgrade flags (old names still work in v4 but print a deprecation warning)
helm upgrade myapp ./chart --rollback-on-failure   # replaces --atomic
helm upgrade myapp ./chart --force-replace          # replaces --force

# post-renderers are plugins now: pass a plugin name, not an executable path
helm template myapp ./chart --post-renderer my-postrenderer

Server-side apply: new installs versus upgrades

This is the subtle one. Helm 4 defaults to Kubernetes server-side apply, but only when you install a brand-new release. When you upgrade or roll back an existing release, Helm keeps whatever apply method that release already used — which means every release originally created by Helm 3 stays on client-side apply after you move to Helm 4. You do not silently switch apply strategies on your production workloads just by upgrading the binary, and that is deliberate.

Helm 3 versus Helm 4 at a glance

My migration checklist

I treat a Helm major upgrade like any other dependency bump: change it in a low-stakes place, watch the output, then roll it wider. Here is the order I follow.

# 1. Check what you are running today
helm version            # client version
kubectl version         # cluster version

# 2. Install Helm 4, then read your existing release history (unchanged from v3)
helm ls -A

# 3. New installs get server-side apply by default
helm install myapp ./chart

# 4. Existing Helm 3 releases keep client-side apply on the first v4 upgrade
helm upgrade myapp ./chart

• Record your current client and cluster versions, and confirm your charts still template cleanly under Helm 4 with helm template.
• Search your CI and local scripts for helm registry login with a URL, --atomic, --force, and executable post-renderers, then fix each one.
• Rename atomic to rollback-on-failure and force to force-replace now, even though the old flags still warn, so you are not chasing warnings later.
• Repackage any post-renderer logic as a Helm plugin and reference it by name instead of by path.
• Upgrade one non-critical release first and confirm it stays on client-side apply, then opt it into server-side apply deliberately and watch for field conflicts.
• Only after that dry run, roll the Helm 4 binary out across the rest of your pipelines and clusters.

None of this is dramatic if you do it before the deadline. Helm 4 keeps your charts working, the renamed flags degrade gracefully with warnings, and the apply-strategy split protects your existing releases from surprise behavior. The real risk is leaving it until Helm 3 security support ends in February 2027 and then discovering a broken login command in a pipeline you forgot about. Start with one cluster this quarter.