Helm 4 vs Helm 3: What Changed, and Why Helm 3 Ends in February 2027

Every Kubernetes platform I have worked on in fourteen years had Helm somewhere in its deploy path, usually inside a CI script nobody had read since the person who wrote it moved teams. Those scripts now have a deadline. Helm 4 shipped in November 2025, the last Helm 3 feature release came out on 9 September 2026, and Helm 3 gets its final security patch on 10 February 2027. This post covers what changed in Helm 4 compared to Helm 3, which changes break pipelines, what the Bitnami catalogue shake-up did to charts, and where Kustomize and Timoni fit. If you are here because an upgrade just failed, the sibling guide on fixing Helm UPGRADE FAILED errors is the faster read.

When was Helm 4 released, and what is the latest version?

Helm 4.0.0 was released on 12 November 2025 at KubeCon + CloudNativeCon North America in Atlanta, the first new major version in six years, in the year the project turned ten. The major bump was needed because the planned architectural changes could not be made without breaking the public Go SDK, now at helm.sh/helm/v4. Charts barely changed: per the 4.0.0 release notes, apiVersion: v2 charts, almost every chart in use, keep working.

Since then a minor release has shipped every four months or so, paired with a same-day Helm 3 release. As of 31 October 2026 the current versions are 4.3.1 and 3.22.1, both published on 15 October. Under the version skew policy, Helm 4 supports the Kubernetes version it was compiled against and three older ones, so 4.3.x covers Kubernetes 1.34 to 1.37.

Release	Date	What it added	Source
4.0.0	12 Nov 2025	WebAssembly-capable plugins, server-side apply, kstatus waiting, content cache, reproducible archives, SDK v4	release notes
4.1.0	21 Jan 2026	Explicit --wait strategies, custom kstatus readers in the SDK, --server-side honoured by upgrade --install	release notes
4.2.0	14 May 2026	Kubernetes 1.36 libraries, mustToToml, --dry-run=server respects generateName	release notes
4.3.0	9 Sep 2026	helm rollback --description, ownership check before uninstall deletes, faster status watching	release notes
3.22.0	9 Sep 2026	Last Helm 3 minor: dependency updates and Kubernetes 0.37 libraries only	release notes
4.3.1 / 3.22.1	15 Oct 2026	Patch releases; 4.3.1 waits for CRDs to be established under hookOnly	release notes
4.4.0	13 Jan 2027 (planned)	Next minor; no further Helm 3 minors	4.3.1 notes

What changed in Helm 4? Server-side apply comes first

Helm 3 updated objects with a client-side three-way merge of the old manifest, the new manifest and the live object. HIP-0023 replaces that with Kubernetes server-side apply (SSA), GA since Kubernetes 1.22, where the API server does the merge and records which field manager owns every field. Helm registers itself as the manager helm.

The defaults are deliberately conservative. helm install uses SSA. helm upgrade and helm rollback take --server-side=auto, which reuses whatever method the release last used; Helm 4 stores this in a new apply_method field on the release record, and a record without it is treated as client-side. A release created by Helm 3 therefore stays client-side until you run an upgrade with --server-side=true, as the Helm 3 end-of-life post spells out.

What you will notice is conflicts. If someone ran kubectl edit on an image, or an autoscaler owns spec.replicas, SSA refuses the apply and names the field and the other manager instead of letting the last writer win. --force-conflicts makes Helm take ownership (it cannot be combined with --force-replace). HIP-0023 also warns that arrays are merged, server defaults are applied, custom resources are now merged, and a client-side dry run cannot predict the result. In 4.3.1, helm upgrade --dry-run of either kind stops before the apply step, so SSA conflicts only appear on a real upgrade.

I think this is Helm 4's most valuable change and the one most likely to surprise a team. Under client-side apply, field ownership meant "whoever wrote last"; under SSA the cluster tells you when two writers disagree, a boring guardrail that matters more now that controllers and agents write to clusters as often as people do.

GitOps tools adopted Helm 4 differently (more in Argo CD vs Flux in 2026). Flux 2.8, released 24 February 2026, runs real Helm v4 releases with SSA and kstatus health checks as defaults; existing HelmReleases stay client-side until opted in, and a UseHelm3Defaults gate restores the old behaviour. Argo CD 3.5, released 4 August 2026, bundles Helm 4.2 for rendering only, since Argo CD applies manifests itself, and now ignores spec.source.helm.version: v3.

How does --wait work in Helm 4?

Helm 3's --wait used hand-written readiness checks for a fixed list of kinds and polled every two seconds. Helm 4 adds a watcher built on kstatus, the status library Flux uses, which reduces any object, including custom resources that follow the standard conditions convention, to Current, InProgress or Failed.

The flag now takes a value. According to the flag definition in 4.3.1, omitting --wait means hookOnly (hooks only, as Helm 3 did without --wait), bare --wait means watcher, and --wait=legacy keeps the Helm 3 checks. --wait=true and --wait=false still work but log deprecation warnings. --rollback-on-failure switches the strategy to watcher unless you choose another.

Two consequences. Errors improve: instead of a bare context deadline exceeded, the watcher lists each resource that never became ready, with its status and message. And the watcher is stricter: an operator whose custom resource never reports Ready will time out where Helm 3 shrugged, and --wait=legacy is the escape hatch. Helm 4.3.0 also made the watcher faster on large releases by computing statuses concurrently and cutting its resync period from one hour to three minutes.

WASM plugins, post-renderers and OCI digests

The plugin system was rebuilt around typed plugins. A Helm 4 plugin.yaml declares apiVersion: v1 and a type (cli/v1, getter/v1 or postrenderer/v1) plus a runtime: subprocess, the old model of exec'ing a binary, or extism/v1, which runs a WebAssembly module through the Extism Go SDK. The Helm 4 overview recommends the optional WebAssembly runtime for security, rightly: a subprocess plugin runs with your kubeconfig and permissions. Legacy plugins without an apiVersion still load, and helm plugin install now verifies signatures by default. helm-diff added Helm 4's --server-side flag in v3.15.10 in June 2026.

Post-renderers are where the plugin change bites. --post-renderer used to take a path to any executable, and a common pattern was a shell script that piped Helm output through kustomize build. In Helm 4 the flag takes a plugin name, so that script has to be wrapped as a postrenderer/v1 plugin.

On the OCI side, Helm 4 can install a chart by digest (oci://registry.example.com/charts/app@sha256:...) and refuses to install if the digest does not match. That is the chart equivalent of pinning an image by digest. helm registry login now takes a bare host such as ghcr.io, with no scheme or path, as the registries docs describe. Charts v3, the new chart format proposed in HIP-0020, is still experimental in 4.3.1 and only appears behind HELM_EXPERIMENTAL_CHART_V3=1.

Helm 4 breaking changes that will hit your CI scripts

Most Helm 3 workflows keep working, by design. The breaks are small and scattered, so they surface one pipeline at a time. I would grep for these:

• --atomic is now --rollback-on-failure, and --force is now --force-replace. The old names still work with a deprecation warning.
• helm list shows releases in every status by default, and the -a/--all flag is gone, so helm list -a fails with an unknown flag. Use --pending, --failed and friends to filter.
• helm registry login https://ghcr.io/org must become helm registry login ghcr.io.
• helm version --client and helm repo add --no-update were removed.
• Plain-HTTP OCI registries need an explicit --plain-http, per Argo CD's 3.5 notes.

The safest migration is to pin the Helm 4 binary explicitly and change one pipeline at a time. Do not rely on a "latest" installer default; the popular azure/setup-helm action's README says it falls back to a hardcoded v3.18.4 if fetching the latest version fails.

#!/usr/bin/env bash
# deploy.sh: Helm 4 deploy step, tested flags against Helm v4.3.1
set -euo pipefail

HELM_VERSION="v4.3.1"   # pin; Helm 3 security fixes end 10 Feb 2027
curl -fsSLO "https://get.helm.sh/helm-${HELM_VERSION}-linux-amd64.tar.gz"
curl -fsSLO "https://get.helm.sh/helm-${HELM_VERSION}-linux-amd64.tar.gz.sha256sum"
sha256sum -c "helm-${HELM_VERSION}-linux-amd64.tar.gz.sha256sum"
tar -xzf "helm-${HELM_VERSION}-linux-amd64.tar.gz" linux-amd64/helm
export PATH="$PWD/linux-amd64:$PATH"

# Helm 3 era:  helm upgrade --install api ./chart --atomic --wait --timeout 10m
# Helm 4:      --rollback-on-failure replaces --atomic and implies --wait=watcher.
#              --server-side=auto (the default) keeps the release's current apply method;
#              flip one release at a time with --server-side=true after a server dry run.
helm upgrade --install api ./chart \
  --namespace prod \
  --rollback-on-failure \
  --wait=watcher \
  --timeout 10m \
  --history-max 10

When does Helm 3 reach end of life?

The dates moved once. The Helm project's end-of-life post, published 2 June 2026, added one extra limited Helm 3 feature release on 9 September 2026 (it became 3.22.0) and extended security support by three months, from November 2026 to 10 February 2027. Bug fixes stopped with that release. After February 2027 Helm 3 gets nothing, not even client library bumps for new Kubernetes versions.

The good news is that there is no data migration. Helm 4 reads and manages Helm 3 releases as they are, because the storage format did not change: each revision is still a Secret named sh.helm.release.v1.<release>.v<revision>, as storage.go shows. Unlike the Helm 2 to 3 move, there is no conversion plugin: the migration is a binary swap plus flag clean-up, and leaving it until February is the main way to get it wrong.

What happened to Bitnami Helm charts?

Bitnami's catalogue change, effective 28 August 2025, moved existing images, including every versioned tag, to a bitnamilegacy repository that "will receive no further updates or support". A small set of hardened images went to bitnamisecure on the latest tag only, intended for development, and full version support moved to the paid Bitnami Secure Images product. Deletion of the old docker.io/bitnami catalogue was postponed to 29 September 2025, with 24-hour brownouts beforehand.

The charts survived in a weaker form. Packaged charts remain at docker.io/bitnamicharts as OCI artifacts but get no updates, and they do not deploy out of the box unless you override the images. The chart and container sources on GitHub stay Apache 2.0, so you can build both yourself. I covered the image side and the free hardened alternatives in Hardened Container Images in 2026. The Helm lesson is simpler: a chart is a pointer to images, and depending on a chart means inheriting its publisher's image supply chain and business model. Pointing image.repository at bitnamilegacy buys time, not security patches.

Helm vs Kustomize vs Timoni in 2026

Helm is still how most third-party software reaches Kubernetes. Cloud Native Now's write-up of the CNCF survey published in April 2025 put Helm at 75 percent as the preferred package manager, and nearly every vendor ships a chart. The real question is what to use for your own applications.

Tool	Model	Latest release	Distribution	Good fit	Source
Helm	Go templates over YAML, release history in the cluster	4.3.1, 15 Oct 2026	Chart repos and OCI	Third-party software; apps needing rollback history	helm/helm
Kustomize	Template-free overlays and patches, built into kubectl apply -k	5.8.3, 8 Oct 2026	Git directories	Your own apps with a few environment differences	kustomize
Timoni	CUE modules with typed schemas	0.37.0, 30 Oct 2026	OCI artifacts, signable	Type-checked config, if pre-1.0 churn is acceptable	timoni

Kustomize avoids templating entirely, which makes it easy to read and hard to over-engineer, but it has no release concept: no history, no rollback, nothing in the cluster recording what was deployed. That is fine if Argo CD or Flux is your record of state. Stefan Prodan's Timoni is the most interesting alternative: CUE gives you types and validation instead of string templating, and modules ship as OCI artifacts. Its README is honest that it is "still in its infancy" and that the CLI and APIs may change incompatibly, and it has around 2,000 GitHub stars against Helm's 30,000. I would use it for an internal platform where I control both the authors and the consumers, not for software I hand to customers.

A common pattern is to use both: render a vendor chart with Helm, then patch it with Kustomize overlays. Helm 4 makes that slightly more formal, since the post-renderer must now be a plugin.

FAQ

Is Helm 4 backward compatible with Helm 3 charts?

Yes for charts. Charts with apiVersion: v2 install and upgrade under Helm 4, and the new Charts v3 format is still experimental. The incompatibilities are in CLI flags and defaults and in the Go SDK. Test upgrades in staging, because server-side apply can surface field conflicts that client-side apply hid.

Do I need to migrate Helm 3 releases to use Helm 4?

No. Helm 4 reads the same sh.helm.release.v1 Secrets, so existing releases appear in helm list and helm history immediately. They keep client-side apply until you upgrade them with --server-side=true.

When is Helm 3 end of life?

Bug fixes ended with 3.22.0 on 9 September 2026. Security fixes continue until 10 February 2027, after a three-month extension, and then Helm 3 receives no updates of any kind, including Kubernetes client library updates.

Should I turn on server-side apply for existing releases?

Eventually, yes, one release at a time and staging first. List the field managers on the release's objects with kubectl get deploy NAME -o yaml --show-managed-fields; any manager other than helm (an autoscaler, kubectl-edit, an operator) is a likely conflict. Decide who owns each field, often by deleting replicas from charts an autoscaler manages, and use --force-conflicts only when Helm should win.

This quarter I would pin Helm 4.3.1 in one non-production pipeline, grep every deploy script for --atomic, --force, helm list -a, --post-renderer and URL-style registry logins, and fix those before touching apply methods. Then I would move releases to server-side apply one at a time, staging first, after checking each object's managed fields for writers other than Helm, because the conflicts SSA reports are real ownership disputes worth knowing about. Anything still on Bitnami images gets a decision this quarter too: build from source, pay, or switch charts. None of this is hard, and all of it is easier in November than in the second week of February.

Related: Argo CD vs Flux in 2026: GitOps After Argo CD 3.5 and Flux 2.9, Hardened Container Images in 2026: DHI Free, Bitnami Gone, 515 CVEs to 0 and Is Kubernetes Still Worth It in 2026? v1.37, 82% in Production, Real Costs.