Helm is the package manager for Kubernetes that bundles manifests, defaults, and release metadata into reusable charts, making deployments repeatable across environments.
Helm packages Kubernetes manifests into versioned charts with templating, dependency management, and install/upgrade/rollback commands. A release is a deployed instance of a chart with its own configuration and history.
That packaging layer matters because raw Kubernetes YAML does not handle environment-specific values well. Helm separates the reusable template from the values that change per environment, so the same chart can promote from staging to production with one values override. It also tracks release history, which makes rollback a single command instead of manual manifest surgery.
Think of it like this. Think of Helm as apt or brew, but for Kubernetes clusters. The chart is the recipe; values are the ingredients for each environment; releases are the meals actually served.
Charts are directories containing templated Kubernetes manifests, default values, and metadata. helm install creates a release. helm upgrade applies new chart versions or values. helm rollback reverts to a previous release revision. Tiller was the original server-side component; Helm 3 removed it and operates client-side with Kubernetes secrets for storage.
"Helm is required for Kubernetes." It is a convenience layer, not a requirement. "Charts should be monoliths." Overly broad charts couple unrelated services and make safe rollbacks harder. "Helm templates replace parameterization." Templates can become complex; values inheritance and documentation matter more than clever templating.
Reduces duplication and standardizes deployments, but introduces templating complexity and release-state coupling. Best for environment-aware packaging; less ideal for GitOps-first workflows that prefer raw manifests.