Helm 3 End of Life: Migrate to Helm 4 Before February 2027

Helm 3.22.0 shipped September 9. It’s the last feature release Helm 3 will ever get. Security patches run through February 10, 2027 — then nothing. If your team deploys to Kubernetes with Helm, you have about 4.5 months to migrate. The good news: unlike the brutal Helm 2-to-3 transition, this is mostly a binary swap. The bad news: three breaking changes will quietly kill your CI/CD pipelines if you don’t find them before they find you.

What Doesn’t Change

Start here, because the anxiety around Helm version bumps is usually worse than the reality. Helm 4 uses the exact same storage format for release secrets. Your existing releases are safe. Charts built on apiVersion: v2 — the standard since Helm 3 — run without modification. Helm 4 can read all your release history. There’s no migration tooling to run, no data to export, no rollback procedure. You install the new binary, and your existing deployments continue working.

The upgrade complexity lives entirely in your CI/CD scripts, not your charts.

The Three Breaking Changes That Hit Pipelines

1. Post-Renderers Must Become Plugins

If you’re passing a script path to --post-renderer, that stops working in Helm 4. Post-renderers must be registered as named Helm plugins. You need a plugin.yaml file:

name: my-post-renderer
version: "0.1.0"
usage: "Custom post-renderer"
command: "$HELM_PLUGIN_DIR/mutate.sh"

Then reference by plugin name instead of file path:

# Helm 3
helm install myapp ./chart --post-renderer ./scripts/mutate.sh

# Helm 4
helm install myapp ./chart --post-renderer my-post-renderer

If you’re not using post-renderers, skip this section entirely.

2. Registry Login Drops the Protocol

In Helm 4, helm registry login accepts domain names only. The https:// prefix breaks it. This one is easy to miss in testing because it fails at authentication time, not deployment time.

# Breaks in Helm 4
helm registry login https://registry.example.com

# Correct
helm registry login registry.example.com

The HELM_EXPERIMENTAL_OCI=1 environment variable is also gone. OCI support is no longer experimental — it’s always on. Remove that variable from any CI environment that sets it.

3. Two Flags Got Renamed

The old names still work with deprecation warnings for now, but that window won’t stay open forever. Update your scripts now while you’re already touching them.

# Helm 3
helm upgrade myapp ./chart --atomic --force

# Helm 4
helm upgrade myapp ./chart --rollback-on-failure --force-replace

The semantics are identical. It’s a pure rename.

The –wait Trap Nobody Warns About

Helm 4 replaced its readiness detection with kstatus, which tracks per-resource health status accurately. But it requires the watch verb in Kubernetes RBAC, and most Helm service accounts don’t have it. If you upgrade without checking, helm upgrade --wait fails immediately — before any changes apply. Check before you migrate:

kubectl auth can-i watch pods \
  --as=system:serviceaccount:default:helm

If that returns no, add watch to your RBAC ClusterRole before touching the binary.

Server-Side Apply: The Real Reason to Migrate

New installs with Helm 4 use Server-Side Apply by default. If you’ve fought the classic Helm-vs-HPA conflict — where Helm overwrites replica counts managed by the autoscaler — that problem is solved. Field-level ownership tracking means Helm only manages what it owns.

Existing Helm 3 releases migrated to Helm 4 keep client-side apply by default. To opt in explicitly: helm upgrade myapp ./chart --server-side. Test in staging first; SSA surfaces field-ownership conflicts with ArgoCD, kubectl, and Terraform that client-side apply masked. Argo CD users need v3.5 or newer for Helm 4 support.

Migrate Before Mid-January

February 10, 2027 is the hard cutoff, but running a production migration in the two weeks before a deadline is how incidents happen. Target mid-January. Here’s the sequence:

1. Verify RBAC: add watch verb to Helm service accounts
2. Update CI scripts: rename --atomic and --force, fix registry login URLs, remove HELM_EXPERIMENTAL_OCI=1
3. Convert post-renderers to plugins (if applicable)
4. Test with helm upgrade --dry-run in non-production
5. Upgrade binary: brew install helm on macOS, or the install script on Linux

Helm 4 reads your existing releases without any conversion step. Run both binaries side-by-side if you want to test before committing. The official EOL announcement is on the Helm blog. For a complete breakdown of every breaking change, the community has a solid migration guide on DEV.to and a fleet migration playbook for teams managing many releases.

There’s no good reason to wait on this one.