Project: Chart a Production App

Project: Chart a Production App

Everything in this tutorial — templating, named helpers, dependencies, hooks, and versioning — converges here. You will build a production-grade Helm chart for a real-world web service: an API backend backed by Redis, with per-environment value files, a database migration hook, a readiness probe, a PodDisruptionBudget, and RBAC. By the end you will have a chart you can drop into a GitHub Actions pipeline and ship to any Kubernetes cluster without modification.

The application is taskflow-api: a stateless Node.js REST service that reads from Redis (managed externally — AWS ElastiCache in staging/prod, a Helm subchart in dev). It needs a Deployment, a Service, an Ingress, a ConfigMap, a Secret, a ServiceAccount, a PodDisruptionBudget, and an HPA. Every field that differs across environments is exposed as a chart value.

Step 1 — Scaffold and Chart.yaml

Start from the official scaffold and immediately edit Chart.yaml to declare the real metadata, Kubernetes version constraint, and the Redis subchart dependency:

Edit Chart.yaml:

Step 2 — The Master values.yaml

Every environment-varying parameter lives here with safe, minimal defaults (single replica, small resources — fine for dev, overridden for staging/prod). Document every key with a comment; this file is the public interface of your chart.

Step 3 — Templates

Create templates/_helpers.tpl first — the naming helpers every other template will call:

Now create the core manifests. The Deployment is the most complex template — note the security context, the readiness/liveness probes, and how the Redis URL is injected via an environment variable sourced from the ConfigMap:

Create the remaining templates — ConfigMap, Service, Ingress, ServiceAccount, PDB, and HPA:

Step 4 — Per-Environment Values Files

Never use --set for more than one or two scalar values in production. Instead, maintain a values file per environment in a separate deploy/ directory (or a dedicated GitOps repo). The base values.yaml holds safe dev defaults; environment files only override what differs:

Step 5 — Pre-Upgrade Migration Hook

Database migrations must run before the new pods come up. A Helm pre-upgrade Job hook is the canonical pattern:

Step 6 — Install and Verify All Environments

Use helm template locally first — zero cluster access needed — to verify that each environment file renders exactly what you expect. This is a mandatory step before any CI pipeline ships a chart:

What You Have Built

The final chart structure:

This chart encodes six months of hard-won production knowledge into a single deployable unit: it prevents configuration drift across environments, enforces security contexts by default, handles zero-downtime deploys via PDB and rolling update strategy, runs migrations atomically before traffic shifts, and gives you a full audit trail via Helm release history. Every pattern here — the checksum annotation, the conditional PDB, the IRSA annotation path, the per-environment values files — mirrors exactly how mature platform teams package applications at big-tech scale.