Knowing Helm's three core nouns makes every command and every chart's README make sense.
Deploying a real application to Kubernetes takes many objects: Deployments, Services, ConfigMaps, ServiceAccounts, RBAC, Ingress. Helm bundles them into one installable, configurable unit.
Three concepts:
- Chart: a directory (or
.tgzarchive) of templated Kubernetes manifests plus default configuration (values.yaml) and metadata (Chart.yaml). - Release: one installation of a chart in a cluster, with a name. The same chart can be installed many times (
redis-cache,redis-sessions). Helm records each release's history, which is what makes upgrades and rollbacks possible. - Repository: where charts are published, either a classic HTTP chart repo with an
index.yaml, or an OCI registry (the same registries that hold container images). Artifact Hub is the search engine for public charts.
Helm is a client-side tool: there is no server component in the cluster. It renders templates on your machine (or in CI), sends the resulting manifests to the API server with your kubeconfig credentials, and stores release records as Secrets in the release's namespace.
Helm 4, released in late 2025, keeps the same chart format (apiVersion v2) as Helm 3, so charts work with both; differences are mostly in the CLI, plugins and how changes are applied.
Example
helm version
# version.BuildInfo{Version:"v4.0.0", ...}
helm search hub postgresql | head -3 # search Artifact Hub
helm list -A # releases in all namespaces
# NAME NAMESPACE REVISION STATUS CHART APP VERSION
# monitoring obs 7 deployed kube-prometheus-stack-77.0.0 v0.85.0
kubectl get secrets -n obs -l owner=helm
# sh.helm.release.v1.monitoring.v7 helm.sh/release.v1 ...Remember
- Chart = package, release = installed instance, repository = where charts live
- Helm runs client-side and stores release history as Secrets
- One chart can be installed as several releases