# Helm's chart is a Chart.yaml and some templates, and v3 has a dated exit

> Helm packages pre-configured Kubernetes resources as charts, renders them, and talks to the API server, which makes it the apt or yum of a cluster. Two version lines are alive at once: v4 is stable on main, while v3 sits on dev-v3 with bug fixes already ended on 2026-07-08 and security fixes promised only to 2026-11-11.

**helm/helm** — The Kubernetes Package Manager

- Repository: https://github.com/helm/helm
- Website: https://helm.sh
- Stars: 30,295 · Forks: 7,816
- Language: Go
- License: Apache-2.0
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/helm-helm

## A chart is Chart.yaml plus template manifests

The unit of distribution is a chart, and a chart is deliberately small. It contains at least two things: a description of the package in Chart.yaml, and one or more templates holding Kubernetes manifest files. Helm renders those templates and communicates with the Kubernetes API, which is why it is described as the tool that handles installing and managing Kubernetes applications, comparable to apt, yum, or homebrew for a cluster rather than for a laptop. A chart can sit on disk or be fetched from a remote chart repository, with the README drawing the parallel to Debian or RedHat package repositories, and Artifact Hub is the discovery point for shared charts. Nothing in the format requires anything else, so the smallest useful chart is a metadata file and one manifest, and the largest is whatever a platform team is willing to review before publishing.

## v3 bug fixes ended 2026-07-08, security fixes end 2026-11-11

Two version lines are alive and the boundary between them is dated. Helm v4 is the current stable release, developed on the main branch. Helm v3 is in support mode on the dev-v3 branch, and the README gives both cutoffs in one sentence: bug fixes until July 8th 2026 and security fixes until November 11th 2026. The first of those dates has already passed, so a v3 user receives security patches only, and has until 2026-11-11 for those too. The tag list shows both lines shipping in the same week, with v4.3.0 on 2026-09-09 and v3.22.0 on 2026-09-10, meaning the patch release for the older major landed a day after the newer major. Progress is tracked through GitHub milestones rather than a roadmap document.

## Seven package managers, one needing --classic

Installing means putting the helm binary on your PATH, and the README names seven package managers that will do it for you:

```bash
brew install helm
choco install kubernetes-helm
winget install Helm.Helm
scoop install helm
snap install helm --classic
flox install kubernetes-helm
mise use -g helm@latest
```

Two details in that list deserve a pause. The Snap package is installed with --classic, which is not a default anywhere else and exists because strict confinement would stop the client from reaching the cluster configuration it needs. And the Chocolatey and Flox packages are called kubernetes-helm while Homebrew, Scoop, Winget, and Mise call it plain helm, so an automation script written against one registry will not find the other. Everything listed here is the client only. Pre-release builds are left to the installation guide rather than spelled out as commands.

## Charts come from git, OCI registries, and a KEYS file

Three chart sources are wired into the dependency list and they are not interchangeable. Masterminds/vcs fetches charts from a version control host, distribution/distribution/v3 and oras-go handle container registries, and a chart can equally be a directory on disk. Signing sits alongside all of that: a KEYS file sits in the repository root as the trust anchor for chart provenance, so a chart fetched from a remote repository can be checked against known keys rather than merely downloaded. Concurrency is handled with gofrs/flock, a cross-platform file lock, which matters because two helm processes sharing one repository cache would otherwise race on the same index file. Nearby dependencies cover the supporting work, with BurntSushi/toml parsing repository configuration and Masterminds/semver resolving version constraints.

## Plugins run on an embedded wazero runtime

WASM support is visible in the module file rather than in the README, and it is the largest departure from what a package manager used to do. The dependency list carries tetratelabs/wazero, an embedded WebAssembly runtime, next to the Extism SDK, and together they mean plugins execute as sandboxed WASM inside the client rather than being compiled into it. Nothing else in the dependency set works that way, which indicates the plugin boundary is WASM by design rather than a Go plugin interface. The practical effect is that a chart author can ship behaviour without shipping a binary, and a cluster administrator can bound what that behaviour is allowed to touch. The README does not describe the plugin interface itself, so where to begin writing one is not answered by this repository.

## Nine release architectures, CGO off, tests in a sibling repo

The Makefile describes the distribution more precisely than the README does. TARGET_OBJS enumerates well beyond the usual pair: darwin amd64 and arm64, linux amd64, 386, arm, arm64, loong64, ppc64le, s390x, and riscv64, plus windows amd64 and arm64, each shipped alongside a .sha256 and a .sha256sum file. CGO_ENABLED defaults to 0 and LDFLAGS strips with -w -s, so every artifact is a static binary with no libc dependency, which is what lets one client run in a distroless container and on a laptop. Binaries are cut with goreleaser, expected on PATH through GOBIN, and the test suite runs with -shuffle=on -count=1 so a green run is not a cached one. Unit tests live in this repository, while acceptance tests are checked out into a separate acceptance-testing repository beside it.

## Kubernetes libraries pinned at 0.37, module path says v4

The module identity carries the version story on its own. It is helm.sh/helm/v4 with go 1.26.0, and the Kubernetes client libraries are pinned together at v0.37.0, from client-go and apimachinery through cli-runtime, apiserver, apiextensions-apiserver, and kubectl. Alongside them sit controller-runtime, kustomize/kyaml for YAML handling, fluxcd/cli-utils for cluster apply workflows, and cobra with pflag for the command tree. One dependency is worth naming for security review: cyphar/filepath-securejoin, a path traversal guard used when unpacking chart contents. Repository housekeeping shows in the top-level entries, with OWNERS, ADOPTERS.md, AGENTS.md, SECURITY.md, a .golangci.yml for linting, a .goreleaser.yaml, and a testdata directory. The code is Apache-2.0 licensed, and the last push to the repository was on 2026-09-30.

## Conclusion

Helm fits a team that ships the same Kubernetes application to more than one cluster and would rather parameterize the manifests than copy them, since the chart format, a Chart.yaml plus templates, is small enough to learn in an afternoon. It does not fit a project that wants one toolchain across a major version boundary, because v4 is stable on main while v3 sits on dev-v3 with security fixes promised only until 2026-11-11, which puts a deadline on every v3 deployment. Verify two things before adopting: which line your tooling expects, given that v3.22.0 shipped on 2026-09-10, a day after v4.3.0 on 2026-09-09, and whether your charts travel as OCI artifacts or from a repository index, because the module carries both oras-go and Masterminds/vcs and they authenticate differently. If you build from source, the Makefile pins CGO off and expects goreleaser on PATH through GOBIN.

## FAQ

### What is Helm used for?

Helm manages Charts, which the README defines as packages of pre-configured Kubernetes resources. It is used to find and run shared software packaged as charts, to publish your own applications as charts, to create reproducible builds of Kubernetes applications, to manage manifest files, and to manage releases of Helm packages.

### What are Helm and Helm charts?

Helm is the tool and a chart is the package. A chart contains at least two things: a description of the package in Chart.yaml, and one or more templates containing Kubernetes manifest files. Helm renders those templates and communicates with the Kubernetes API, and charts can live on disk or be fetched from remote chart repositories.

### Is Helm free to use?

Helm is published under the Apache-2.0 license, with the LICENSE file at the repository root, and the README describes no paid tier or subscription. Installing the client costs nothing, since it is available as a binary from the releases page and through seven package managers.

### Is a Helm chart the same thing as Helm?

No. Helm is the client that renders templates and talks to the Kubernetes API. The chart is the package it renders, made of a Chart.yaml description plus one or more template files containing manifest files, stored on disk or fetched from a remote chart repository.

### What are the differences between Helm 2 and Helm 3?

The README does not discuss Helm 2. It states that Helm v4 is the current stable release developed on the main branch, and that Helm v3 is in support mode on the dev-v3 branch with bug fixes until 2026-07-08 and security fixes until 2026-11-11.

## Sources

- [Official documentation](https://helm.sh)
- [Official README](https://github.com/helm/helm#readme)
- [Project repository](https://github.com/helm/helm)
- [Release notes](https://github.com/helm/helm/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/helm-helm