helm-charts

Helm Charts

Helm exists to solve one problem: the same application needs slightly different manifests in dev, staging, and prod, and copy-pasting YAML across environments guarantees drift. A chart is a template plus a values contract — the moment the templates start encoding environment-specific logic instead of taking it as input, the chart has stopped doing its job.

The values file is the API of the chart; everyone who consumes it, including future-you, should be able to configure the workload without reading the templates. A chart is good if you can predict its rendered output from values.yaml alone.

1. Design values.yaml as a contract, not a dump

Every value you expose is something a consumer now depends on — expose too little and people fork the chart to add one setting; expose too much and every value becomes load-bearing forever. The right test: does this need to vary by environment or by deployer? If not, it's a template default, not a value.

• Group by concern, not by template file — resources, ingress, image as top-level keys that read naturally, matching how consumers think about the workload.
• Document every value's type and default in values.yaml comments or a schema (values.schema.json) — undocumented values get set wrong silently.
• Never require a values override just to make the chart install — sane defaults should produce a working (if minimal) deployment with zero overrides.

Done when: someone unfamiliar with the templates can configure the chart correctly using only values.yaml and its comments.

2. Layer environment overrides, don't fork the chart

The failure mode past "quick chart" is a values-prod.yaml that has silently drifted from values-dev.yaml in ways nobody can diff meaningfully, or worse, three near-identical chart copies. Helm's -f flag composes multiple values files in order — use that composition instead of duplicating the whole file per environment.

helm upgrade myapp ./chart -f values.yaml -f values-prod.yaml --install