Helm and Helm Chart

Helm — Comprehensive Production Guide

Helm eliminates the chaos of managing 5-6 separate Kubernetes YAML files per service. Instead of manually editing Deployment, Service, Ingress, and ServiceAccount manifests for every deploy, Helm packages them into one versioned chart and applies them with a single command.

REMEMBER THIS

**Remember:** Helm is to Kubernetes what `npm` is to Node.js — a package manager that handles versioning, upgrades, and rollbacks.

Helm Chart

A chart is the core Helm unit — a folder containing all Kubernetes manifest templates and configuration defaults for one application.

Chart structure

Chart.yaml

REMEMBER THIS

**Remember:** `version` is the chart version — bump it every time you change templates. `appVersion` is the version of the application itself.

Templates use Go template variables that Helm fills at deploy time:

PLACEMENT PRO TIP

**Tip:** Always add `extraVolumes` and `extraVolumeMounts` support to your deployment template from the start. Adding them later requires a chart version bump and redeployment.

values.yaml

The default configuration file for a chart. All tunable parameters live here — image tag, replica count, resource limits, env vars. Environment-specific files like dev.values.yaml override these defaults at deploy time.

Base values.yaml

Environment override — dev.values.yaml

Only include keys you want to override. Everything else falls back to values.yaml:

COMMON MISTAKE / WARNING

**Common Mistake:** Putting secrets as plain text in `values.yaml` committed to your repo. Always use `secretKeyRef` pointing to a Kubernetes Secret, and store actual values in AWS Secrets Manager or Vault.

Helm Release

A running instance of a Helm chart deployed to a Kubernetes cluster. The same chart can be installed multiple times as different releases — each with its own name, namespace, and values. Helm tracks each release's revision history, enabling instant upgrades and rollbacks.

Core release commands

Revision history example

COMMON MISTAKE / WARNING

**Security:** Rollback restores Kubernetes resource config only — Deployment spec, env vars, image tag. It does NOT revert database migrations or external state. Always test rollback in staging before a production incident.

PLACEMENT PRO TIP

**Tip:** Always use `--atomic` in production pipelines. If new pods fail health checks, Helm automatically rolls back to the previous revision without manual intervention.

Helmfile

A declarative wrapper on top of Helm. Instead of running separate helm upgrade commands for each environment, Helmfile lets you define all releases, charts, and environment-specific values in one helmfile.yaml — deploying everything with a single helmfile apply command.

helmfile.yaml

Deploy commands

How value merging works

Helmfile layers values files in order — later files override earlier ones:

REMEMBER THIS

**Remember:** Helmfile only upgrades releases that have actual changes — it runs `helm diff` internally and skips unchanged releases. This makes `helmfile apply` safe to run on every pipeline push.

OCI Chart Registry

Helm charts can be stored in any OCI-compatible container registry alongside Docker images. AWS ECR, GitHub Container Registry, and Docker Hub all support OCI chart storage — no separate chart server needed.

Push chart to ECR

Reference OCI chart in helmfile.yaml

COMMON MISTAKE / WARNING

**Common Mistake:** Using a flat ECR repo name like `devops-network-helm`. ECR OCI push requires the full nested path — `devops-network-helm/devops-network-chart` as the repository name. Creating the repo with just the parent name will cause a push failure.

Quick Reference