Dora NodaTwo days ago, Helm 3 received its last feature release ever. Version 3.22.0, shipped September 9, 2026, contains Kubernetes client-library updates and nothing else — no backported features, no more minors after it. Security patches continue until February 10, 2027. After that date, Helm 3 gets nothing: no CVE fixes, no client updates for new Kubernetes versions, no releases of any kind.
If your fleet's charts are deployed by Argo CD or Flux rather than a human running helm upgrade, this is your timeline now. The good news, straight from the maintainers' end-of-life announcement: charts deployable with Helm 3 should be deployable by Helm 4, and releases managed by Helm 3 should generally be upgradable by Helm 4. And Helm 4 is no longer the new kid — 4.0 shipped in November 2025, the line is at 4.3.x today with 4.4.0 scheduled for January 2027, and the surrounding ecosystem (Minikube's default client, Kubermatic's installer, Calico, Istio docs) has already crossed over. There is no flag day. But "should generally upgrade" still leaves a concrete checklist — post-renderers, registry logins, CLI flags, chart API versions, and your GitOps controller's own Helm version — and the five months between now and February are when that checklist gets worked, not admired.
Here is the playbook: the exact dates, what Helm 4 actually changes for a GitOps-managed fleet, what breaks, and whether to move now or ride the sunset.
The expiry dates, without euphemism
The official timeline from the Helm maintainers' June 2026 EOL post:
| Date | What happens |
|---|---|
| September 9, 2026 | Final Helm 3 feature release (3.22.0) — Kubernetes client-library updates only, no other backports |
| September 9, 2026 | Bug fixes for Helm 3 stop |
| February 10, 2027 | Security patches for Helm 3 stop — extended three months past the original November 2026 date to give the community migration room |
| After February 2027 | No Helm 3 releases of any kind, including Kubernetes client-library and security patches |
Two details matter more than they look. First, the September release exists almost entirely so Helm 3 keeps working against new Kubernetes versions a little longer — it is life support, not development. Second, the February cutoff includes client-library updates, which means a Helm 3 binary will silently age out of compatibility with the clusters it deploys to. A fleet that rides the sunset past February isn't just accepting unpatched CVEs in its packaging tool; it is accepting a deploy tool that gradually stops understanding the API servers it talks to.
The ecosystem is already moving. Minikube switched its default in-guest Helm client from 3 to 4 citing exactly this timeline, and projects from Kubermatic to Calico to Istio have all landed Helm 4 compatibility or server-side-apply fixes in the last two release cycles. Helm 3 in late 2026 is where Python 2 was in late 2019: everything still works, and everything around you is quietly leaving.
What Helm 4 buys a GitOps fleet: field ownership
Helm 4's headline change is server-side apply (SSA), and it is the one Helm 4 feature that directly pays rent on a GitOps-managed fleet.
Under Helm 3, the client performs a three-way merge and patches whole resources. When two managers touch the same object — say, Helm owns a Deployment but a HorizontalPodAutoscaler mutates its replica count, or Argo CD and Helm both write annotations — Helm 3's merge logic decides the outcome by overwriting fields it doesn't own. The classic symptom: a GitOps sync fight where the HPA scales to five replicas, the next Helm-driven sync stamps the charted value back, and operators learn to paper over it with ignore-differences rules they don't fully understand.
Server-side apply moves that bookkeeping to the API server. Every field has a recorded owner, and an apply operation only touches the fields its manager owns. Helm 4 becomes one well-behaved citizen among several — kubectl, Argo CD, your operators — instead of the citizen that rewrites the whole street. For a fleet where charts are reconciled by controllers rather than applied by humans, this is the single biggest reliability upgrade in the release: fewer phantom diffs, fewer sync waves fighting autoscalers, fewer 3 a.m. pages caused by two tools disagreeing about who owns replicas.
The migration path here is deliberately gentle. Helm 4 uses server-side apply by default for new releases, but upgrades latch to whatever apply method the release already used — a release created by Helm 3 keeps getting client-side merges until you explicitly flip it with --server-side. Your existing fleet doesn't change behavior the day you swap the binary. That latching is the maintainers telling you, in API design, that there is no flag day.
What actually breaks: the short, honest table
"Charts deployable with Helm 3 should be deployable by Helm 4" covers charts. The breakage lives in the workflows around them — CI scripts, wrapper tooling, and CLI muscle memory. Every item below comes from the maintainers' own breaking-changes list:
| Helm 3 | Helm 4 | Who feels it |
|---|---|---|
--post-renderer /path/to/binary | --post-renderer <plugin-name> — post-renderers must be registered plugins | Anyone running kustomize or env-subst as a post-render step in CI; wrap the script with a plugin.yaml and helm plugin install it |
helm registry login https://registry.example.com | Domain names only: helm registry login registry.example.com | Registry login steps in pipelines; full URLs are rejected |
--atomic | --rollback-on-failure | Every deploy script written since 2019; the old flag still works but emits a deprecation warning, so this is a grep-and-replace, not an outage |
--force | --force-replace | Same treatment: deprecated alias, not a hard break |
requirements.yaml / requirements.lock | Gone under the new apiVersion: v3 chart format | Charts still carrying v1-era dependency files; modern apiVersion: v2 charts with a dependencies: block are unaffected |
HELM_EXPERIMENTAL_OCI=1 | OCI registry support is stable and on by default; setting the old env var errors | Pipelines that export the experimental flag — delete the line |
Two more changes deserve a row in spirit. Post-renderers can now process hook resources, which closes a long-standing gap for teams that render CRDs or hook manifests through kustomize — if your pipeline post-renders hooks today via a workaround, test the native path under Helm 4 and delete the workaround. And Helm 4 ships an optional WebAssembly plugin runtime alongside the classic plugin system — existing plugins keep working, so this is additive, not a rewrite mandate.
What about hooks themselves, the behavior change the migration guides flag? The honest answer is that hook semantics and CRD handling are largely unchanged — Helm 4 still has no proper CRD lifecycle management, so resources deployed as hooks purely to control ordering or to update immutable fields keep working exactly as before, workarounds included. That is good news for migration effort (nothing to rewrite) and bad news for anyone hoping the major version would retire the pattern (it didn't). Audit which of your hooks exist for ordering versus which exist to dodge the CRD limitation; the former can stay, the latter should be tracked as tech debt Helm 4 does not pay down. If half your resources are hooks because that's the only way to control ordering, that workaround migrates with you untouched.
The GitOps wrinkle: your controller has a Helm version too
On a GitOps fleet, nobody runs the helm binary directly — Argo CD's repo-server and Flux's helm-controller embed Helm as a library. Swapping your laptop's binary changes nothing about what actually renders your staging environment. The migration unit is the controller version, and that has three consequences.
First, check support before you plan anything. Argo CD added Helm 4 support in the v3.5 line and SSA awareness from v3.3 onward; Flux has Helm v4 support on its 2026 roadmap with its helm-controller tracking the new libraries. Concretely: inventory every Argo CD and Flux instance in the fleet, note its version, and confirm Helm 4 compatibility in its release notes. A management cluster running last year's Argo CD is the thing standing between you and Helm 4, not your charts.
Second, remember the latching behavior cuts both ways. Because upgrades keep the release's original apply method, flipping a controller to Helm 4 does not silently convert your whole fleet to server-side apply — existing releases stay client-side until something explicitly re-applies them server-side. That is safe, but it means "we upgraded the controller" and "we get SSA's benefits" are two separate milestones. Plan the second one: after the controller upgrade, roll a no-op re-apply or a regular release cycle with --server-side set so each release's newest revision records the new method, then verify field ownership looks right before declaring victory.
Third, watch the SSA edge cases the early adopters already found. Calico had to fix a create-on-apply path where server-side apply arrived as update-with-create-allowed and returned NotFound for resources that didn't exist yet; Istio published SSA caveats for helm template workflows, explicitly including Argo CD and Flux pipelines. The pattern: anything that renders manifests outside a real apply — helm template piped to kubectl, template-based diff previews — can behave differently under SSA assumptions. If your GitOps setup diffs with helm template anywhere (dry-run previews, policy checks, admission previews), test that path specifically. It is the one place where "the binary changed but behavior latched" does not protect you.
Move now or ride the sunset? A decision, not a vibe
The maintainers gave you a five-month security-only window. Here is how to spend it:
Move now if any of these are true: you run post-renderers as raw executables (the plugin rewrite is the longest pole — start it first); your controllers are already on Helm-4-capable versions (the marginal cost is a canary, so take the win); you fight HPA-or-operator sync wars today (SSA is the actual fix, and every month of phantom diffs is toil you chose); or your compliance posture can't tolerate a packaging tool with a published end-of-patches date (auditors read EOL announcements too).
Ride the sunset — deliberately, until January — if: your fleet is large, your charts are apiVersion: v2 with no post-renderers, and your controllers trail current releases. Helm 3.22 plus security patches is a supported configuration until February 10, and a rushed fleet-wide controller upgrade in December is worse than a scheduled one in January. But put the January date in the tracker now, with an owner. "Ride the sunset" without a calendar entry is just procrastination with a strategy document.
Either way, the checklist is the same:
- Inventory post-renderer executables across every pipeline; convert each to a plugin (
plugin.yaml+helm plugin install). - Grep CI and wrapper scripts for
--atomic,--force, full-URLregistry login, andHELM_EXPERIMENTAL_OCI; fix all four. - Grep charts for
requirements.yamlandapiVersion: v1; modernize what you find. - Inventory Argo CD / Flux versions across management and workload clusters; upgrade controllers to Helm-4-capable releases in non-production first.
- Canary one application end-to-end: controller upgrade, release, explicit
--server-sidere-apply, ownership verification. - Roll the fleet through, oldest controllers first, finishing all production cutovers by mid-January — leaving a buffer before the February 10 cliff, not landing on it.
Six steps, five months, one hard date. That is the whole migration.
The fleet angle
Helm's EOL is a small, well-signposted version of the problem every self-hosted platform eventually faces: the tools under your platform have lifecycles, and the bill comes due on a maintainer's calendar whether or not it suits your roadmap. Fleets managed declaratively — Cluster API for the machines, GitOps for the workloads — absorb these transitions better than hand-operated ones, because the migration unit is a version bump in a manifest rather than a runbook executed server by server. If your charts, controllers, and cluster definitions all live in git, the Helm 4 migration is six checklist items. If they don't, it is an archaeology project with a February deadline.
Running your own fleet means owning days like this one — and getting the tooling that makes them boring. Bex.co is the open-source, AI-native Render alternative: push a git repo, get a running HTTPS service on machines you own. Star the repo or deploy your first app today.
Sources
- Helm maintainers, "Helm 3 End of Life" (June 2, 2026) — helm.sh/blog/helm-v3-end-of-life: final 3.x September 9, 2026; security fixes through February 10, 2027; breaking-changes and new-features lists.
- Helm project, "Helm 4 Overview" — helm.sh/docs/overview: SSA default for new releases with latching to the previous apply method on upgrade/rollback.
- Helm v4.3.0 release notes — confirms no further Helm 3 minor releases after 3.22.x and the patch schedule into late 2026.
- Minikube PR/issue upgrading the default in-guest Helm client to v4 — cites the September 2026 / February 2027 timeline as motivation.
- Kubermatic installer PRs (#16138, #16148) —
--server-side/--force-conflictshandling and--atomic→--rollback-on-failuretranslation under Helm 4. - Calico PR #12905 and Istio docs PR #17230 — SSA create-on-apply edge case and
helm templatecaveats affecting Argo CD / Flux workflows. - Amaresh Pelleti, "Helm 4 Migration Guide: What Breaks and How to Fix It Before EOL" (July 2026); Sylvain Gibier, "Helm v4 vs. v3: Understanding the Key Differences" (
apiVersion: v3, post-renderers over hooks); Ilya Lesikov, "Helm v4: key changes from v3" (CRD-management limits carry over). - The Stack Observer on Argo CD v3.5 (mutual TLS, Helm 4 support); Flux 2026 roadmap notes on Helm v4 support.
