Helm 3 Bug Fixes Are Over: A Fleet Owner's Migration Checklist for the Security-Only Runway to February 2027

Five weeks ago, the package manager underneath nearly every Kubernetes deploy quietly stopped accepting bug fixes. Helm 3's final feature release shipped on September 9, 2026, and from that day forward the only Helm 3 releases you will ever see are on-demand security patches — until February 10, 2027, when those stop too, including Kubernetes client-library updates. If your fleet still templates tenant workloads and platform components with Helm 3, you are now living inside a five-month runway with a hard wall at the end.

Worse, you are sharing that runway with a second deadline. Kubernetes 1.34 reaches end-of-life across the managed platforms in the same quarter, so the team that owns cluster upgrades and the team that owns chart tooling — often the same tired humans on a self-hosted fleet — are spending the same upgrade windows. This post gives you the dated timeline, the honest definition of "security fixes only," the migration-target decision, and the ordered checklist to get off Helm 3 before the wall.

The clock: two EOLs, one quarter​

Here is every date that matters, in one table. Helm dates come from the Helm 3 end-of-life announcement; Kubernetes dates from the 1.34 end-of-life rundown.

Two things to notice. First, the Helm wall is the last date on the board but the least flexible: there is no paid extended support to buy your way out, no LTS channel, no vendor to call. After February 10, Helm 3 is frozen forever. Second, everything between now and February competes for the same change windows. A self-hosted fleet that upgrades its clusters to 1.35 or 1.36 in December while still deploying with Helm 3 is testing a combination — new API server, frozen deploy tooling — that nobody upstream is testing anymore. Schedule the Helm migration before or alongside the cluster upgrades, not after them.

What "security fixes only" actually covers​

The announcement's security-window rules fit in three sentences, and each one bites a different assumption:

1. No new features will be backported to Helm 3, including updates to Kubernetes client libraries. This is the one most teams miss. Your Helm 3 binary's understanding of the Kubernetes API is now frozen at whatever client libraries 3.22.x shipped with. New server versions, new API shapes, new deprecation removals — Helm 3 will never learn about them.
2. Only security patches will be released, on demand, as needed. There is no patch train. If a vulnerability is found, a release goes out; if the quarter is quiet, nothing ships. Do not read silence as health.
3. No bug fixes will otherwise be applied. A regression you hit in October stays a regression in February. Your only fix is upgrading to Helm 4 or working around it.

The practical consequence is a slow divergence. Every cluster upgrade from here on widens the gap between what your API servers speak and what your deploy tooling understands. That gap is silent right up until it is a failed deploy at 2 a.m. — a removed beta API, a changed defaulting behavior — with no upstream fix coming. The window is not "five months of normal with a deadline"; it is five months of growing skew.

Pick the migration target first​

Before touching a single pipeline, decide where you are going. There are three serious answers, and the right one depends on how Helm reaches your clusters today.

That caveat: GitOps operators embed their own Helm. Argo CD and Flux do not shell out to your CI's helm binary; they compile Helm libraries into the controller. Moving your pipelines to GitOps without checking the operator's Helm version just relocates the deadline into someone else's release notes.

If you pick this target, the checklist item becomes "track the operator release that vendors Helm 4 libraries, and upgrade the operator" — a real plan, but one with a dependency you do not control. For most fleets, Helm 4 directly is the shortest path past the wall: the migration guide is five steps, and the breaking surface is four items long.

The four things that break on the way to Helm 4​

Helm 4 shipped in November 2025 with server-side apply by default, a WebAssembly plugin runtime, kstatus-based status tracking, multi-document values, and a stable SDK. The maintainers' compatibility promise is generous: charts deployable with Helm 3 should deploy with Helm 4, and Helm 4 upgrades Helm 3 releases without migration steps. What breaks is not your charts — it is the automation wrapped around them. Four things, each with a mechanical fix:

1. Post-renderers become plugins. helm install --post-renderer no longer takes an executable path. If your pipeline pipes manifests through kustomize or a policy injector this way, that invocation fails under Helm 4 until the renderer is registered as a post-renderer plugin.

# Helm 3: path to an executable
helm upgrade --install myapp ./chart --post-renderer ./render.sh
 
# Helm 4: name of a registered plugin
helm upgrade --install myapp ./chart --post-renderer my-renderer

Audit every --post-renderer flag in CI configs, Makefiles, and wrapper scripts. This is the most common silent breaker because the flag still exists — it just means something narrower now.

2. Registry login takes domains, not URLs. helm registry login accepts only a domain name, laying groundwork for per-scope authentication. Any OCI workflow logging in with a full URL needs editing.

# Helm 3: full URL worked
helm registry login registry.example.com/charts -u robot -p secret
 
# Helm 4: domain only
helm registry login registry.example.com -u robot -p secret

3. Two flags get renamed. --atomic becomes --rollback-on-failure and --force becomes --force-replace. The old spellings still work but emit deprecation warnings, so this one degrades loudly rather than silently — grep your pipelines and rename at leisure, but rename before warnings become errors in some future major.

4. Server-side apply latches per release. Helm 4 defaults to server-side apply for new releases, but when upgrading an existing Helm 3 release it follows that release's previous apply method. That latching is the safe default — mixed field-management across an upgrade is exactly the conflict server-side apply exists to surface. Override it deliberately with --server-side=false only if you have measured a reason; otherwise let old releases stay client-side and let new releases be server-side from birth.

None of this requires rewriting charts, redeploying releases, or a flag day. The upgrade is a binary swap validated release by release — which is exactly what the checklist sequences.

The fleet checklist: audit, pin, freeze, roll​

Work this list in order. Each step is small; together they carry a fleet from "still on Helm 3, vaguely worried" to "migrated, with receipts."

1. Audit every Helm in the fleet — binaries and embedded copies. Inventory the helm version in CI images, Makefiles, developer setups, and any version-pinned installer scripts. Then inventory the Helm you do not invoke directly: the Argo CD or Flux version on each cluster and the Helm library it vendors. One fleet I have seen had three Helm versions: CI pinned, developers floating, and the operator a minor behind both. Write all of them down; the migration is not done until every entry reads Helm 4 (or an operator release built on it).

2. Pin everything Helm 3 to the final patch line. Until each deploy path migrates, pin it to the latest 3.22.x patch so a stray floating install cannot land on an older, buggier 3.x with no fix coming. Treat unpinned Helm installs the way you would unpinned base images: a reproducibility bug that is now also a security posture bug.

3. Freeze charts by triage, not by blanket decree. "No chart changes until migration" is unenforceable and wrong — security bumps still need to ship. Triage instead: platform components (ingress, monitoring, operators) freeze except for CVE fixes; third-party charts freeze at current versions and get their Helm 4 compatibility checked from upstream changelogs; tenant workload charts keep shipping normally, since Chart API v2 charts move to Helm 4 unchanged and freezing tenant deploys would stall the business to protect the tooling. The freeze protects the migration surface, not the product.

4. Build the non-prod test matrix. In a staging cluster, exercise Helm 4 against one release of each shape you run: a plain chart, a chart with a post-renderer, an OCI-sourced chart, and an in-place upgrade of a release Helm 3 created (verifying the apply-method latch). Run your actual CI jobs, not hand-typed commands — the breaking surface lives in automation, so the test must run the automation. Log every flag rename, login change, and plugin registration the matrix surfaces; that log becomes the production rollout script.

5. Roll production in stages, release by release. Upgrade the binary (or operator) in one environment at a time, letting Helm 4 adopt existing releases in place. Watch the first upgrades for field-ownership conflicts on releases that operators or hand-edits also touch — server-side apply surfaces those instead of silently overriding them, which is a feature that feels like an incident the first time. Keep Helm 3 binaries available for rollback during the window, and retire them per environment as each one goes green.

6. Schedule against the cluster upgrades, not after them. If your 1.34 exit lands in December and your Helm migration lands in January, you spent a month deploying to new clusters with frozen tooling. Pair the changes in the same maintenance windows: migrate a cluster's deploy path when you migrate the cluster. The fleet that finishes both by year-end gets to ignore February entirely.

The wall itself needs no drama. February 10, 2027 is four months away; the migration is a tested binary swap with four known automation fixes and no chart rewrites. What turns it into an incident is discovering in February that some forgotten CI image or embedded operator Helm was still on 3.x — which is exactly what step one prevents. Start with the audit this week, and the rest is scheduling.

Running your own fleet means owning both sides of this deadline — the clusters and the tooling that deploys to them. Bex.co is the open-source, AI-native Render alternative that keeps that ownership practical: push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API your existing pipelines already speak. Star the repo on GitHub or deploy your first app today.