What Is Helm in Kubernetes

1What Is Helm?

Helm is the package manager for Kubernetes. It bundles the many YAML manifests an application needs — deployments, services, config maps, ingress rules — into a single versioned package called a chart, which you install, upgrade, or roll back with one command.

Think of it the way apt or npm work for their ecosystems. Instead of running kubectl apply against a dozen hand-edited files and hoping they stay in sync, you install a chart, pass in a few values, and Helm renders and applies everything for you as one coordinated release.

2Why Helm Matters

Raw Kubernetes manifests get painful fast. The same app usually needs slightly different settings per environment, and copy-pasting YAML leads to drift and mistakes.

• Templating: one chart deploys to dev, staging, and prod with different replica counts, image tags, and hostnames.
• Versioning: every release has a revision number, so you always know what is running and can roll back.
• Reuse: community charts let you install Postgres, Redis, or an ingress controller without writing manifests by hand.
• Atomic operations: helm upgrade applies all changes together, and --atomic rolls back automatically if the release fails.

3Anatomy of a Chart

A chart is just a directory with a specific structure. Understanding these files is most of what you need to read or write one.

• Chart.yaml: metadata — the chart name, version, and app version.
• values.yaml: default configuration values that templates read from.
• templates/: the templated Kubernetes manifests, written in Go template syntax.
• templates/_helpers.tpl: reusable template snippets like standard labels.
• charts/: optional subcharts this chart depends on.

4The Core Commands

You can be productive with Helm using just a handful of commands. Each maps to a clear lifecycle step of a release.

• helm install myapp ./mychart # create a new release from a local chart
• helm install web bitnami/nginx # install from a repository
• helm upgrade myapp ./mychart --values prod.yaml # apply changes
• helm rollback myapp 1 # revert to revision 1
• helm list # show installed releases in the namespace
• helm uninstall myapp # remove the release and its resources

5Releases and Revisions

A release is a specific installed instance of a chart, identified by the name you give it. Installing the same chart twice with different names produces two independent releases, each with its own configuration.

Every upgrade creates a new revision, and Helm keeps the history. If revision 4 breaks production, helm rollback myapp 3 restores the previous known-good state in seconds without you having to remember what the manifests looked like.

6Chart Repositories and Artifact Hub

You rarely start from scratch. Public chart repositories host maintained charts for common infrastructure, and Artifact Hub is the searchable index that ties them together.

• helm repo add bitnami https://charts.bitnami.com/bitnami # register a repo
• helm repo update # refresh the local cache of available charts
• helm search repo postgres # find matching charts
• helm show values bitnami/postgresql # inspect configurable values before installing

7Best Practices

A few habits keep Helm charts safe and maintainable as your cluster grows.

• Never commit real secrets to values.yaml — use a secrets manager or tools like sealed-secrets and inject at deploy time.
• Pin chart and image versions rather than using latest, so deploys are reproducible.
• Keep environment differences in separate values files (values-prod.yaml) instead of duplicating whole charts.
• Run helm lint and helm template in CI to catch template errors before they reach a cluster.
• Use --atomic on upgrades so a failed release rolls back automatically instead of leaving a half-applied state.

8Common Mistakes to Avoid

Most Helm trouble comes from a small set of avoidable habits rather than the tool itself.

• Editing live resources with kubectl instead of the chart — the next helm upgrade silently reverts your change.
• Putting plaintext passwords in values files that then land in Git history.
• Ignoring the difference between chart version and app version, which makes rollbacks confusing.
• Skipping --dry-run and discovering a bad template only after it hits production.

9Key Takeaways

The essentials of Helm come down to a few durable ideas.

• Helm is Kubernetes' package manager: it turns loose manifests into versioned, configurable charts.
• A chart is templates plus values; a release is an installed instance with a revision history.
• install, upgrade, and rollback make deployments single-command and reversible.
• Use community charts from repositories and Artifact Hub instead of reinventing infrastructure.
• Keep secrets out of values files, pin versions, and dry-run before applying.

10Frequently Asked Questions

Q: Is Helm required to use Kubernetes? A: No. You can deploy everything with plain kubectl and YAML. Helm becomes valuable once you manage many manifests, multiple environments, or want easy versioned rollbacks — which is most real-world clusters.

Q: What is the difference between Helm 2 and Helm 3? A: Helm 3 removed Tiller, the server-side component that Helm 2 needed, so Helm now talks directly to the Kubernetes API using your kubeconfig. This made Helm simpler and more secure, and Helm 3 is the current standard.

Q: What is a values.yaml file? A: It holds the default configuration values a chart's templates read from. You override any of them at install or upgrade time with --set or a custom values file, which is how one chart serves many environments.

Q: Can I roll back a Helm release? A: Yes. Helm keeps a revision history for each release, so helm rollback myapp 3 restores the exact state of revision 3, including its configuration, in seconds.