Helm 4.2 Migration Guide: Helm 3 Ends November 2026

Helm 3 has a confirmed death date: November 11, 2026. That’s five months away. Helm 4.2 shipped on May 14 and is stable. For most Kubernetes teams, the migration is less disruptive than it sounds — your chart files don’t change, and most CLI usage is identical. But three things will silently break in CI pipelines if you don’t act, and all three are fixable in under an hour. Here’s what to fix and when to move.

The EOL Timeline You Should Actually Care About

The November 11 date is the one that gets headlines, but the more important deadline is July 8, 2026 — when Helm 3 stops receiving bug fixes and enters security-only mode. After that, you’re accumulating unpatched bugs in production while waiting for a security patch that may never come for your specific issue.

• July 8, 2026: Helm 3 enters security-patch-only mode (bug fixes stop)
• November 11, 2026: All Helm 3 support ends

Migrate before July, not November. The five-month buffer is false comfort.

Three Breaking Changes That Will Hit Your CI/CD

Charts don’t break. Almost nothing in your day-to-day Helm CLI usage breaks. But if you’re running automation, exactly three things will fail without warning.

1. Post-Renderers Must Be Registered as Plugins

In Helm 3, you could pass an executable path directly to --post-renderer. Helm 4 drops that. The script needs to be wrapped as a named Helm plugin and referenced by name.

# Helm 3 — breaks in Helm 4
helm upgrade myapp ./chart --post-renderer ./scripts/mutate.sh

# Helm 4 — register the plugin first, then reference by name
helm upgrade myapp ./chart --post-renderer my-post-renderer

Your script doesn’t need to change. Create a plugin.yaml, run helm plugin install ./my-post-renderer, and you’re done. The executable-direct path is the only thing removed.

2. Registry Login Drops the URL Scheme

As of Helm 4.1, helm registry login no longer accepts URLs with https://. Domain only.

# Helm 3 — breaks in Helm 4.1+
helm registry login https://registry.example.com/

# Helm 4
helm registry login registry.example.com

This one silently breaks every CI pipeline using the old format. Grep your GitHub Actions, GitLab CI, and shell scripts for helm registry login https:// and fix them before migration day.

3. Go SDK Import Path Changed (Tool Builders Only)

If you build Go tooling that embeds Helm as a library — operators, controllers, custom wrappers — the module path changed from helm.sh/helm/v3 to helm.sh/helm/v4. Application operators who only run Helm commands can skip this entirely.

# Update all import paths at once
find . -name "*.go" -exec sed -i 's|helm.sh/helm/v3|helm.sh/helm/v4|g' {} +
go mod tidy

Note: the Terraform Helm provider has an open tracking issue for Helm v4 support. Check your provider version before migrating if you use Terraform to manage Helm releases.

Why Helm 4 Is Worth the Migration (Not Just Compliance)

Helm 4 is the first major release in six years. The headline feature, Server-Side Apply, fixes a real bug that has been frustrating platform teams since Helm 3 launched.

Helm 3’s three-way merge couldn’t reliably clean up deleted fields. Remove a label from your chart, run helm upgrade, and that label could silently persist on the cluster because Helm lost track of it. SSA fixes this by handing field ownership to Kubernetes — the API server tracks which tool owns which fields and cleans them up correctly on every apply.

There’s another benefit for multi-tool setups: if Argo CD and Helm both manage the same resource, Helm 4 raises an explicit conflict error instead of silently overwriting. That’s the behavior you actually want.

One nuance: SSA applies to new installs only. Existing releases migrated from Helm 3 continue using client-side apply until you reinstall them. You won’t get SSA benefits on legacy releases without a full reinstall.

What Else Is New in Helm 4

OCI digest pinning: You can now install charts by SHA256 digest instead of a mutable tag. Helm rejects charts whose digest doesn’t match — a direct answer to supply chain concerns.

helm install myapp oci://registry.example.com/charts/app@sha256:52ccaee6d4dd272e54bfccda77738b42e1edf0e4a20c27e23f0b6c15d01aef79

Wasm plugins: The plugin system is rebuilt around OCI distribution and optional WebAssembly sandboxing via Extism runtime. Traditional executable plugins still work. The Wasm runtime is opt-in, not mandatory.

Multi-document values files: You can now use --- separators in a values file to group configurations without multiplying -f flags.

Deprecated flags (warnings, not errors for now): --force is now --force-replace; --atomic is now --rollback-on-failure. Update your scripts before these become hard errors in a future minor release.

Migration Checklist

1. Audit post-renderers: Find any --post-renderer usage pointing to an executable path. Wrap each as a Helm plugin.
2. Fix registry login calls: Search CI configs for helm registry login https:// and drop the scheme.
3. Update Go SDKs (if applicable): Replace helm.sh/helm/v3 imports with helm.sh/helm/v4, run go mod tidy.
4. Rename deprecated flags: Replace --force with --force-replace and --atomic with --rollback-on-failure in scripts.
5. Test against Helm 4.2: Run your full chart test suite before cutting over production pipelines.

Most teams complete this in a few hours. The chart files themselves don’t require changes — existing Helm Chart API v2 charts are fully compatible with Helm 4. The upgrade is less about rewriting and more about auditing the automation wrapper around Helm.