Helm 3.22.0 Is the Last Release: Upgrade Before February

Helm 3.22.0 shipped September 9. If you missed the official announcement on helm.sh, you’re forgiven — it was brief. What isn’t brief is the consequence: that release is the last feature update Helm 3 will ever get. Helm 4.3.0 dropped the same day. You now have a hard deadline — February 10, 2027 — and four CI/CD breaking changes to audit before you swap the binary.

The Timeline You Need to Know

Earlier this year, the headline was “Helm 3 ends November 2026.” That turned out to be off. The final Helm 3 feature release landed September 9, three months ahead of the original estimate. Security patches still run until February 10, 2027 — but after that date, no more releases of any kind: no CVE fixes, no Kubernetes client updates, nothing.

Five months is enough time to migrate, but not enough time to be casual about it. The four breaking changes below are where pipelines will break silently if you upgrade the binary without auditing first.

The Four Breaking Changes in Your CI/CD

1. helm registry login No Longer Accepts a URL

This one has the widest blast radius and the most silent failure mode. Helm 4 requires a domain name only — no scheme, no path:

# Helm 3 — breaks silently in Helm 4
helm registry login https://ghcr.io/

# Helm 4 — correct
helm registry login ghcr.io

Grep every GitHub Actions workflow, GitLab CI file, and shell script for registry login https:// before you touch the binary. While you’re there, remove HELM_EXPERIMENTAL_OCI=1 from your environment — OCI support is stable and default in Helm 4, and that env var now causes a hard error.

2. –atomic and –force Got Renamed

--atomic is now --rollback-on-failure. --force is now --force-replace. The old flags still work, but they emit deprecation warnings — and if your pipeline treats warnings as failures (GitHub Actions with set -e, GitLab with strict failure modes, most mature CI setups), your deploy jobs break the moment you swap the binary.

# Before
helm upgrade myapp ./chart --atomic --wait

# After
helm upgrade myapp ./chart --rollback-on-failure --wait

Scan your Makefiles, shell wrappers, and CI definitions:

grep -r "\-\-atomic\|\-\-force\b" .github/ .gitlab-ci.yml Makefile scripts/

3. –wait Now Requires watch RBAC Permission

Helm 4 uses the kstatus library for wait operations instead of polling. kstatus relies on Kubernetes watch events, which means your Helm service account needs the watch verb on every resource type your chart deploys — not just list.

If that permission is missing, --wait fails immediately after upgrade, before any chart change even applies. Check now:

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

This catches teams running minimal RBAC in dev clusters or internal tooling environments. Add watch to your ClusterRole before migrating.

4. Post-Renderers Must Be Plugins

In Helm 3, --post-renderer ./scripts/kustomize.sh accepted an arbitrary executable path. Helm 4 takes a plugin name instead. Post-renderers now run as WebAssembly modules inside Helm’s new Wasm plugin runtime — better security isolation, but it requires packaging your post-renderer as a postrenderer/v1 plugin before you can use it.

If you’re not using post-renderers, skip this one. If you are, budget time to package and test before migration day.

The Server-Side Apply Change

Helm 4 defaults to server-side apply (SSA) for new installations. For existing Helm 3 releases, upgrades automatically continue using client-side apply — Helm detects the pattern. Most running workloads won’t be disrupted on upgrade.

The risk is specific: if you manage the same Kubernetes resources with both Helm and another tool (Argo CD, Flux, manual kubectl), SSA can produce field manager conflicts. Run helm upgrade --dry-run against your production charts and check the output before swapping the binary cluster-wide.

What Helm 4.3.0 Gives You

There’s a real reason to upgrade beyond just not being stranded on an unsupported version. Helm 4.3.0 ships content-based chart caching — the cache key is now a hash of chart content rather than name and version, eliminating cache collisions when different charts share the same name and version string. Dependency resolution is roughly 60% faster. The WebAssembly plugin runtime adds security isolation. And Charts v3 development is now unlocked, which is where the longer-term roadmap lives.

How to Migrate Without Breaking Production

Don’t migrate everything at once. Start with one non-critical cluster: run the grep audit, fix the four breaking changes, run helm upgrade --dry-run on your most complex charts, then apply. Once that cluster runs cleanly for a week, roll out to the rest.

The Helm 4 docs cover the full breaking change list. The Helm 4.3.0 release is available now. The February deadline gives you enough runway to be methodical — use it.