Helm v4.3.0 packages Kubernetes applications as charts
Helm v4.3.0 turns Kubernetes manifests into a versioned chart with configurable values. The client renders templates, submits the resources to the Kubernetes API, and stores a release record. Operators can inspect revisions, upgrade, roll back, or uninstall one named release. This model suits software that must be distributed to customers or repeated across clusters without copying directories of YAML.
Charts travel through repositories or OCI registries, while Artifact Hub helps users find them. The Helm quick-start guide demonstrates an OCI install and release management. A chart can carry dependencies and notes alongside templates. Vendors gain one installable package whose users can set image tags, storage classes, ingress names, and resource limits.
One binary is easier than the 341-package source build
The README recommends a release binary or one of 7 named package managers. That is the sensible path for most users. Building the 4.1 MB source checkout pulled 341 Go packages in our sandbox and spent 178 seconds compiling. Contributors can follow that route, while platform teams should pin an official binary, verify its checksum, and leave the Go toolchain out of deployment images.
Cluster actions need a Kubernetes cluster, a kubeconfig, and sufficient API permissions. Private OCI registries add their own login. Local rendering with helm template needs no cluster credential, which is useful in review jobs that should never receive one. The setup difficulty sits mostly in access policy and chart inputs, since installing the client itself can be a single binary copy.
What happened when we ran it
Our sandbox installed 341 packages in 46 seconds, built Helm in 178 seconds, and completed tests in 151 seconds. Go reported 118 passed and 0 failed out of 118. We ran commit 62c7e84 in a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM, following our testing method. Every measured step exited successfully.
The checkout held 2,014 files, about 107,876 source lines, and occupied 4.1 MB before dependencies. Our scan found 8 CI workflow files, no Dockerfile, and no top-level tests directory. Go still found and passed 118 package-level tests. We did not connect the binary to Kubernetes, install a chart, or exercise registry authentication.
The 151-second green suite establishes that commit 62c7e84 builds and passes its available tests in the stated Go 1.24 environment. It says nothing about a particular chart's templates, hooks, container images, or Kubernetes compatibility. Each chart needs its own rendered-manifest review and cluster test, because Helm can be sound while the package it applies is unsafe.
Two required chart parts can grow into another configuration language
A chart starts with at least 2 parts: Chart.yaml metadata and one or more templates. Values feed Go templates, whose helpers, conditions, loops, and dependencies can support many environments. The price is review complexity. Teams should render the exact values, lint the chart, validate schemas, and run policy checks before an upgrade. A small set of plain overlays may remain easier to inspect in Kustomize.
Nine hook types can leave resources behind
The chart hook guide defines 9 hook points for install, upgrade, delete, rollback, and tests. Hooks can run backup Jobs or remove a service from rotation. Helm waits for Job and Pod hooks, and a failure can fail the release. Subchart hooks also run, while the parent chart has no switch to disable them.
Hook-created resources are not tracked as ordinary release members. The guide says uninstall cannot be trusted to remove them unless the chart sets a deletion policy or a Job TTL. This matters during cleanup and namespace retirement. Release history is useful, but it is not a complete inventory of every object created during hook execution.
Helm 4 wait behavior needs workload-specific tests
Open issue 31766 reports intermittent v4.1.0 timeouts when uninstall with wait and foreground cascading handles cluster-scoped resources. Kubernetes had deleted the objects, according to the report, while Helm saw them as terminating until timeout. The reporter gives wait=legacy as a workaround. This single report justifies an uninstall regression test without establishing a general defect.
The Helm 4 overview asks users to test all 3 plugin types, CI scripts, post-renderers, registries, and complex applications. Post-renderers now use plugin names, registry login takes a domain, and renamed flags warn. New releases default to server-side apply; Helm 3 releases retain client-side apply unless changed. A staged v4 migration remains necessary even with chart compatibility.
September activity and 118 passing tests support production use
GitHub listed 30,233 stars and 461 open issues and pull requests, including 258 true open issues. The repository was pushed on September 9, 2026, and open items changed on September 11. Helm v4.3.0 arrived September 9 with chart-loading, provenance, template-output, and archive fixes. The dates show active maintenance alongside a large support queue.
The README still gives November 11, 2026 as Helm 3's security cutoff. The newer official Helm 3 end-of-life notice extends fixes through February 10, 2027, after which no updates are promised. New deployments should use v4. Existing v3 estates have a defined window to test their plugins, flags, registries, and apply behavior.
Argo CD or Flux should own continuous reconciliation
Helm v4 runs from a laptop, CI job, SDK, or another controller; it does not keep checking live resources against Git. Argo CD and Flux supply that loop, and Flux can manage Helm releases. Kustomize handles YAML overlays without release state. Choose Helm when charts and named history help. Its 118 passing tests and current v4.3.0 release support that choice, provided teams render packages, audit hooks, and test changes before applying them.