Helm — Overview#

Identity#

Purpose#

Helm is the package manager for Kubernetes — analogous to apt/yum/homebrew but for deploying containerized applications onto a cluster. It manages “Charts,” which are bundles of templated Kubernetes manifest files plus metadata, and tracks them as versioned “releases” so that installs, upgrades, and rollbacks can be performed as atomic operations. Its primary audience is platform engineers, DevOps teams, and application developers who need repeatable, auditable deployments on Kubernetes.

Significance#

Helm is one of the most widely adopted tools in the Kubernetes ecosystem and is a graduated CNCF project. Virtually every Kubernetes user encounters it; ArtifactHub alone hosts tens of thousands of public Charts. It defines the canonical packaging format for Kubernetes applications, meaning its design decisions (Chart structure, template engine, release model) have shaped how the entire community thinks about Kubernetes software distribution. Helm v4 (this branch) is under active development, carrying forward API-breaking improvements while v3 remains the stable branch on dev-v3.

Key metrics#

  • Go files: 534
  • Top-level directories: cmd/, internal/, pkg/, scripts/, testdata/
  • Direct dependencies: ~47 (in first require block of go.mod)
  • Indirect dependencies: ~110+ (second require block; 523 lines in go.sum)
  • Repository age: First released ~2015; this clone reflects recent activity (March 2026)

Notable characteristics#

  • Template engine via Sprig/Go templates: Helm’s core value proposition is rendering Kubernetes YAML through Go’s text/template engine augmented by Masterminds/sprig, enabling rich parameterization without a separate DSL.
  • OCI registry support: Helm v3/v4 uses OCI registries (via oras.land/oras-go and distribution/distribution) to store and distribute Charts alongside container images, reflecting a major architectural evolution from the HTTP chart repo model.
  • WASM plugin system (v4): The inclusion of extism/go-sdk and tetratelabs/wazero signals a new extensibility model in v4: plugins can be compiled to WebAssembly and run sandboxed inside the Helm process, a significant departure from the subprocess plugin model in v3.
  • SQL-backed storage (v4): Dependencies on jmoiron/sqlx, lib/pq, rubenv/sql-migrate, and Masterminds/squirrel reveal that Helm v4 introduces SQL (PostgreSQL) as a release storage backend alongside the existing Kubernetes Secrets/ConfigMaps approach.
  • Deep Kubernetes integration: The k8s.io/* dependency surface (api, apimachinery, apiserver, cli-runtime, client-go, kubectl) is extensive, reflecting that Helm does not shell out to kubectl but drives the Kubernetes API directly via client-go, including server-side apply semantics via fluxcd/cli-utils.
Backward K3s — Testing Helm — Structure Forward