Devtips

Helm Charts: Templating & Multi-Environment Kubernetes Deployments

Mohammad Abu Mattar 30 Mar, 2026 04 Mins read

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 but with different replicas, resource limits, environment variables. Copy-paste the YAML, make a few edits, and deploy. Works fine until someone edits dev and forgets to update staging. Or production has a typo and nobody notices until users report the outage.

Helm packages Kubernetes applications, providing templating, versioning, and dependency management transforming “paste YAML and hope” into “deploy with confidence.”

The Manual YAML Approach Breaks At Scale

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 Solution: Helm Charts

What is Helm?

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

Core Benefits

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: [email protected]

Templating: The Power of Helm

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

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 Helm 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 }}

Conditional Resources

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 Policies

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 (Right-to-left 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

Depends on PostgreSQL

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

Install Dependencies

# Download dependencies
helm dependency update

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

Values for Dependencies

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

Helm Release Management

Basic Deployment

# 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

Deployment Workflow

# 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

Store 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 Workflow 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

Advanced Templating

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 and Iterations

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

Best Practices

1. Semantic Versioning for Charts

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. Helm Lint Before 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. Values Schema Validation

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
}

Real-World Example: Complete Deployment

Minimal Chart Structure

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

Deploy

# 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

Conclusion

Helm transforms Kubernetes deployments from manual tedium to automated simplicity.

By templating your manifests, managing values per environment, and versioning releases, you eliminate the fragility of manual YAML management. Combined with GitOps tools like ArgoCD, Helm becomes the backbone of reliable, repeatable Kubernetes deployments.

Helm Charts: Templating & Multi-Environment Kubernetes Deployments

You might also enjoy