Helm chart passing multiple environment values for single key
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
When deploying applications to Kubernetes with Helm, you often need to pass environment variables to containers. Helm templates use Go templating to dynamically generate the env section of pod specs from values.yaml. This article covers how to define environment variables in Helm values files, iterate over them in templates, and handle different environments (dev, staging, production).
Basic Environment Variables in Helm
values.yaml
deployment.yaml template
The toYaml function converts the list to YAML, and nindent 12 indents it correctly within the container spec.
Using a Map Instead of a List
A map (dictionary) is often cleaner and easier to merge across environments:
values.yaml
deployment.yaml template
The range iterates over the map and creates an env entry for each key-value pair. Using quote ensures values are properly quoted in YAML.
Mixing Static and Dynamic Values
Combine hardcoded env vars with values from ConfigMaps and Secrets:
values.yaml
deployment.yaml template
Per-Environment Configuration
Use separate values files for each environment:
values-dev.yaml
values-prod.yaml
Deploy with the appropriate values file:
Using envFrom to Load All Keys from ConfigMap/Secret
This loads all keys from the ConfigMap or Secret as environment variables without listing each one individually.
Conditional Environment Variables
Merging Values with --set
Override or add individual env vars at deploy time:
Common Pitfalls
- Numeric values need quoting: YAML interprets
5432as an integer, but Kubernetes env var values must be strings. Usequotein templates:value: {{ $value | quote }}to ensure values like port numbers are rendered as"5432". - Indentation errors:
toYamloutput must be indented correctly in the deployment template. Usenindent N(notindent N) to handle both the newline and indentation. Wrong indentation causes cryptic Kubernetes deployment errors. - Map key ordering: Go templates iterate over maps in sorted key order. If you need a specific order, use a list instead of a map.
- Overriding list items with --set:
--set env[0].name=VARsyntax is fragile with lists. Prefer using a map structure for env vars so you can override with--set envVars.KEY=value. - Secret values in values.yaml: Never put actual secrets (passwords, API keys) in
values.yaml. Use Kubernetes Secrets withvalueFrom.secretKeyRefor external secret managers (Vault, AWS Secrets Manager).
Summary
- Define env vars as a map in
values.yamlfor easy merging and overriding - Use
rangeto iterate over the map and generateenventries in the deployment template - Use
valueFromwithsecretKeyRefandconfigMapKeyReffor sensitive or external values - Create per-environment values files (
values-dev.yaml,values-prod.yaml) and deploy with-f - Always
quotevalues in templates to prevent YAML type coercion issues
Related reading
- Helm Chart will install manually, will not install via Terraform
- Helm charts and Ingress resources
- Helm configmap error Error UPGRADE FAILED ConfigMap my-service.v130 is invalid data Too long must have at most 1048576 characters
- helm error Error This command needs 2 arguments release name, chart path
- Helm how to define .Release.Name value
- Helm Incompatible versions between client and server
- helm error when updating UPGRADE FAILED The order in patch list
- Helm export YAML files locally just use templating engine, do not send to Kubernetes

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.