Devtips

Helm Charts: Templating & Multi-Environment Kubernetes Deployments

Mohammad Abu MattarPublished: 30 Mar 202604 Mins read04 Mins listen

Why Helm matters

The Kubernetes manifest problem

Managing Kubernetes manifests at scale becomes a nightmare.

You have a deployment for dev, staging and production. Each one is 90% identical: same containers, same services, different replicas and resource limits and environment variables. Copy the YAML, edit a few lines, deploy. That works right up until someone edits dev and forgets staging, or a typo lands in production and nobody notices until users report the outage.

Helm packages a Kubernetes application as a chart with templates, values and a version number. The YAML you deploy is generated from one source instead of maintained in three places.

Where hand-written YAML breaks down

1
Environment Fragmentation:
2
prod-deployment.yaml  ← Different values hardcoded
3
staging-deployment.yaml  ← Needs 3 edits for prod
4
dev-deployment.yaml  ← Inconsistent structure
5

6
Result:
7
• Configurations drift
8
• Changes in one place aren't replicated
9
• Rollback = manually revert files
10
• New environments = copy-paste hell

The fix: Helm charts

What Helm is

Helm is package management for Kubernetes, like npm for Node.js or pip for Python.

Charts: Helm packages containing templated Kubernetes manifests
Values: Configuration that gets injected into templates (replicas, image tags, resources)
Releases: Deployed instances of charts, tracked with versions for easy rollback
Repos: Central repositories where teams share charts

What you get

Single chart, multiple environments: Use template variables instead of duplicating YAML
Templating system: {{ .Values.replicas }} → substituted with values from env-specific file
Dependency management: Charts can depend on other charts (PostgreSQL, Redis, etc.)
Versioning & rollback: Every deployment tracked, instant rollback to previous version
Validation: Helm validates charts before deployment
GitOps ready: Store charts in Git, deploy from Git

Chart structure

Directory layout

1
my-app/
2
├── Chart.yaml                 # Chart metadata (name, version, description)
3
├── values.yaml                # Default values
4
├── values-dev.yaml            # Dev environment overrides
5
├── values-staging.yaml        # Staging overrides
6
├── values-prod.yaml           # Production overrides
7
├── templates/
8
│   ├── deployment.yaml        # Templated Kubernetes Deployment
9
│   ├── service.yaml           # Service manifest
10
│   ├── configmap.yaml         # ConfigMap for config
11
│   ├── hpa.yaml               # Horizontal Pod Autoscaler (prod only)
12
│   └── _helpers.tpl           # Template helpers/functions
13
└── README.md                  # Chart documentation

Chart.yaml

1
apiVersion: v2
2
name: my-app
3
description: A Helm chart for my microservice
4
type: application
5
version: 1.0.0 # Chart version
6
appVersion: '1.2.3' # Application version
7
maintainers:
8
  - name: Your Team
9
    email: team@example.com

Templating

Basic values templating

1
# Default values for all environments
2
replicaCount: 1
3

4
image:
5
  repository: myregistry.azurecr.io/my-app
6
  tag: '1.2.3'
7
  pullPolicy: IfNotPresent
8

9
resources:
10
  requests:
11
    memory: '128Mi'
12
    cpu: '100m'
13
  limits:
14
    memory: '256Mi'
15
    cpu: '500m'
16

17
environment: 'dev'
18
debug: true

1
# Production overrides
2
replicaCount: 3 # More replicas for load
3

4
resources:
5
  requests:
6
    memory: '512Mi'
7
    cpu: '500m'
8
  limits:
9
    memory: '1Gi'
10
    cpu: '2000m'
11

12
environment: 'production'
13
debug: false # Disable debug logging

A templated deployment

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: {{.Release.Name}}
5
  namespace: {{.Release.Namespace}}
6
spec:
7
  replicas: {{.Values.replicaCount}} # Injected from values
8
  selector:
9
    matchLabels:
10
      app: {{.Chart.Name}}
11
  template:
12
    metadata:
13
      labels:
14
        app: {{.Chart.Name}}
15
    spec:
16
      containers:
17
        - name: {{.Chart.Name}}
18
          image: '{{ .Values.image.repository }}:{{ .Values.image.tag }}'
19
          imagePullPolicy: {{.Values.image.pullPolicy}}
20
          env:
21
            - name: ENVIRONMENT
22
              value: {{.Values.environment}}
23
            - name: DEBUG
24
              value: '{{ .Values.debug }}'
25
          ports:
26
            - containerPort: 8080
27
          resources:
28
            requests:
29
              memory: {{.Values.resources.requests.memory | quote}}
30
              cpu: {{.Values.resources.requests.cpu | quote}}
31
            limits:
32
              memory: {{.Values.resources.limits.memory | quote}}
33
              cpu: {{.Values.resources.limits.cpu | quote}}

Conditional logic in templates

Environment-specific configuration

1
spec:
2
  {{- if eq .Values.environment "production" }}
3
  replicas: 3
4
  {{- else if eq .Values.environment "staging" }}
5
  replicas: 2
6
  {{- else }}
7
  replicas: 1
8
  {{- end }}

Resources that exist only in some environments

1
{{- if eq .Values.environment "production" }}
2
apiVersion: autoscaling/v2
3
kind: HorizontalPodAutoscaler
4
metadata:
5
  name: {{ .Release.Name }}
6
spec:
7
  scaleTargetRef:
8
    apiVersion: apps/v1
9
    kind: Deployment
10
    name: {{ .Release.Name }}
11
  minReplicas: 3
12
  maxReplicas: 10
13
  metrics:
14
  - type: Resource
15
    resource:
16
      name: cpu
17
      target:
18
        type: Utilization
19
        averageUtilization: 70
20
{{- end }}

Conditional security settings

1
spec:
2
  {{- if eq .Values.environment "production" }}
3
  securityContext:
4
    runAsNonRoot: true
5
    runAsUser: 1000
6
    fsReadOnlyRootFilesystem: true
7
  {{- end }}

Managing multiple environments

Environment-specific values files

1
Deploy to dev:
2
helm install my-app . -f values.yaml -f values-dev.yaml
3

4
Deploy to staging:
5
helm install my-app . -f values.yaml -f values-staging.yaml
6

7
Deploy to prod:
8
helm install my-app . -f values.yaml -f values-prod.yaml

Values priority (the last one wins)

# Later files override earlier ones
helm install my-app \
  -f values.yaml \           # Base defaults
  -f values-prod.yaml \      # Override for prod
  --set environment=production # Override from CLI (highest priority)

Chart dependencies

Depending on PostgreSQL

1
dependencies:
2
  - name: postgresql
3
    version: '13.0.0'
4
    repository: https://charts.bitnami.com/bitnami

Installing dependencies

# Download dependencies
helm dependency update

# Then deploy (PostgreSQL chart auto-installs)
helm install my-app . -f values-prod.yaml

Values for a sub-chart

1
# My app values
2
replicaCount: 3
3

4
# PostgreSQL sub-chart values
5
postgresql:
6
  enabled: true
7
  auth:
8
    password: 'prod-secure-password'
9
  primary:
10
    persistence:
11
      size: 100Gi
12
  metrics:
13
    enabled: true

Release management

The basic commands

# Install a release
helm install my-app ./chart -f values-prod.yaml

# Upgrade to new version
helm upgrade my-app ./chart -f values-prod.yaml

# Check release history
helm history my-app

# Rollback to previous version (instant!)
helm rollback my-app 2

# Delete release
helm uninstall my-app

A deployment run, start to finish

# 1. Make changes to chart
# 2. Test locally
helm install test-release . -f values-dev.yaml

# 3. Test succeeded, upgrade
helm uninstall test-release

# 4. Deploy to production
helm upgrade my-app . -f values-prod.yaml

# 5. Verify
kubectl get pods -l app=my-app

# 6. If something's wrong, instant rollback
helm rollback my-app

GitOps integration

Storing charts in Git

1
git repository structure:
2
├── charts/
3
│   ├── my-app/
4
│   │   ├── Chart.yaml
5
│   │   ├── values.yaml
6
│   │   ├── values-dev.yaml
7
│   │   ├── values-prod.yaml
8
│   │   └── templates/
9
│   └── other-app/
10
├── .gitignore
11
└── README.md

GitOps with ArgoCD

ArgoCD watches your Git repo and automatically keeps your Kubernetes cluster in sync:

1
apiVersion: argoproj.io/v1alpha1
2
kind: Application
3
metadata:
4
  name: my-app-prod
5
spec:
6
  project: default
7
  source:
8
    repoURL: https://github.com/myteam/infrastructure
9
    targetRevision: main
10
    path: charts/my-app
11
    helm:
12
      values: |
13
        environment: production
14
        replicaCount: 3
15
  destination:
16
    server: https://kubernetes.default.svc
17
    namespace: prod
18
  syncPolicy:
19
    automated:
20
      prune: true
21
      selfHeal: true

Deploy workflow:

1
1. Developer updates Chart in Git
2
2. Commits and pushes
3
3. ArgoCD detects change
4
4. Automatically syncs to Kubernetes
5
5. Helm applies new deployment
6
6. Services updated with zero downtime

Going further with templates

Helper functions

1
{{- define "my-app.labels" -}}
2
helm.sh/chart: {{ include "my-app.chart" . }}
3
app.kubernetes.io/name: {{ include "my-app.name" . }}
4
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
5
{{- end }}
6

7
{{- define "my-app.name" -}}
8
{{ .Chart.Name }}
9
{{- end }}

1
# Reuse helper
2
metadata:
3
  labels: {{- include "my-app.labels" . | nindent 4}}

Loops

1
env:
2
{{- range $key, $value := .Values.env }}
3
- name: {{ $key }}
4
  value: {{ $value | quote }}
5
{{- end }}

Best practices

1. Version charts semantically

1
version: 2.1.0 # MAJOR.MINOR.PATCH
2
# MAJOR: Breaking changes
3
# MINOR: New features
4
# PATCH: Bug fixes

2. Use namespaces

# Deploy each environment to different namespace
helm install app . -n production -f values-prod.yaml
helm install app . -n staging -f values-staging.yaml
helm install app . -n dev -f values-dev.yaml

3. Lint before you deploy

# Validate chart syntax
helm lint ./chart

# Dry-run to see what will be deployed
helm install --dry-run my-app ./chart -f values-prod.yaml

4. Test charts

helm test my-app  # Run chart tests

5. Validate values against a schema

1
{
2
  '$schema': 'https://json-schema.org/draft-07/schema#',
3
  'type': 'object',
4
  'properties':
5
    {
6
      'replicaCount': {'type': 'integer', 'minimum': 1},
7
      'image': {'type': 'object', 'properties': {'tag': {'type': 'string'}}},
8
    },
9
}

A complete minimal example

Chart structure

1
my-service/
2
├── Chart.yaml
3
├── values.yaml
4
├── values-prod.yaml
5
└── templates/
6
    ├── deployment.yaml
7
    └── service.yaml

Deploying it

# Dev
helm install my-service . -f values.yaml -f values-dev.yaml

# Production
helm upgrade my-service . -f values.yaml -f values-prod.yaml --install

# Rollback if needed
helm rollback my-service

Wrapping up

Helm replaces four copies of a deployment with one chart and four values files.

Templated manifests, values per environment and numbered releases mean a rollback is one command instead of an archaeology session in Git history. Pair it with ArgoCD and the cluster follows the repo. The templating language is the price of admission, and it is a real cost, but it buys you environments that actually match.

Resources

Was this useful?

You might also enjoy