Helm

Helm is the de facto package manager for Kubernetes. Instead of applying a dozen separate YAML manifests, you bundle them into a chart — templated manifests plus default configuration — that you can install, upgrade, roll back, and version as a single unit.

Its real value is parameterized, versioned deployments: one chart deploys the same app to dev, staging, and prod with different values, and a bad upgrade can roll back atomically. The discipline that keeps it sane is keeping templates simple and pushing configuration into values.

TL;DR

• A chart packages Kubernetes resources; a release is an installed instance.
• Use helm upgrade --install for idempotent deploys.
• Keep templates boring; put configuration in values.yaml.
• Pin chart and image versions; treat charts as versioned artifacts.

Quick Example

The CI-friendly deploy: idempotent, environment-specific, and auto-rolls-back on failure:

Core Concepts

• Chart — a folder/.tgz with Chart.yaml (metadata), values.yaml (defaults), templates/ (manifests), and optional dependency charts/.
• Release — an installed instance of a chart in a namespace, with a specific set of values.
• Values — configuration inputs that drive how templates render (values.yaml, -f file, --set).
• Templates — Go-templated Kubernetes YAML; Helm just generates manifests you'd otherwise write by hand.

Environment Overrides

Keep defaults in values.yaml and layer per-environment files:

⚠️ Don't put secrets in values files. Wire them in via Kubernetes Secrets or an external secrets system.

Best Practices

• Pin and promote — pin chart and image versions; promote the same artifact dev → staging → prod rather than rebuilding.
• --atomic --wait — roll back automatically and wait for workloads to become ready.
• Treat values.yaml as an interface — document it, avoid breaking keys, optionally validate with values.schema.json.
• Keep templating minimal — simple if blocks and helpers; avoid complex string logic that's hard to review.

Comparison: Helm vs Kustomize

Many teams combine Helm + GitOps — render charts and manage releases declaratively.

Common Mistakes

Secrets in values files

Over-templating

FAQ

What's the difference between a chart and a release?

A chart is the package — templates plus default values — that you can reuse and distribute. A release is one installed instance of that chart in a cluster/namespace, with its own values and revision history. You can install the same chart many times as different releases.

Why use helm upgrade --install instead of helm install?

It's idempotent: it installs the release if it doesn't exist and upgrades it if it does. That single command works the same on first deploy and every subsequent one, which is exactly what you want in CI/CD.

How do I roll back a bad deploy?

Helm keeps revision history, so helm rollback my-app <revision> reverts to a previous release. Better, deploy with --atomic, which automatically rolls back if the upgrade fails to become healthy within the timeout.

Helm or Kustomize?

Helm for packaging and distributing reusable, parameterized applications with versioned charts. Kustomize for overlaying/patching plain YAML in a GitOps-friendly, diff-able way. They're not mutually exclusive — some teams use Helm to package and a GitOps tool to deploy.

Related Topics

• Kubernetes — What Helm deploys to
• Docker — The images charts reference
• CI/CD Pipelines — Where helm upgrade --install runs
• Container Security — Securing deployed workloads
• DevOps — The broader practice

References

• Helm — Documentation
• Helm — Charts
• Helm — Best practices
• Kustomize