Helm in Production

Helm is the package manager for Kubernetes, but using it in production requires more than running helm install. This guide covers advanced Helm concepts used in real-world environments: security, versioning, GitOps, secrets encryption, and best practices for scalable deployments.

1. Helm Architecture in Production

A production-ready Helm setup separates concerns:

  • Chart Repository: Internal OCI registry storing versioned Helm charts
  • Git Repository: Stores values files per environment
  • CD System: ArgoCD or FluxCD applies Helm releases automatically
  • Security Layer: Secrets encrypted with SOPS or Vault

2. Using Helm with OCI Registries

Production clusters increasingly use OCI registries (Artifact Registry, ACR, ECR, Harbor) instead of HTTP Helm repos.

# Authenticate to registry
helm registry login myregistry.com

# Push a chart
helm push mychart-1.2.0.tgz oci://myregistry.com/helm/

# Pull and install
helm pull oci://myregistry.com/helm/mychart --version 1.2.0
helm install app ./mychart

Benefits: Immutable storage, better access control, compatible with enterprise tools.

3. Managing Secrets Securely (SOPS + Helm)

Never store secrets in plain YAML. Use SOPS with GPG, KMS, or Azure/GCP key management.

# Encrypt a YAML file
sops -e values-prod.yaml > values-prod.enc.yaml

# Decrypt automatically during Helm install
helm upgrade --install app mychart \
  -f values-prod.enc.yaml \
  --decrypt

Why SOPS? Git repositories remain safe, and decryption happens only in CI/CD or at deploy time.

4. GitOps with Helm (ArgoCD & FluxCD)

In production environments, manual helm install is avoided. Instead, a GitOps controller continuously reconciles the desired state defined in Git.

ArgoCD Example
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  destination:
    namespace: prod
    server: https://kubernetes.default.svc
  source:
    repoURL: https://github.com/org/env-config
    path: charts/myapp
    helm:
      valueFiles:
        - values-prod.yaml
  syncPolicy:
    automated: { }
FluxCD Example
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: myapp
spec:
  chart:
    spec:
      chart: myapp
      sourceRef:
        kind: HelmRepository
        name: internal-repo
  valuesFrom:
    - kind: ConfigMap
      name: prod-values

GitOps Advantages: auditability, rollback, immutability, zero manual drift.

5. Helm Chart Versioning Strategy

Good versioning avoids breaking production environments.

  • MAJOR — breaking changes in templates or required values
  • MINOR — new features but backward compatible
  • PATCH — bug fixes, no template change
# Chart.yaml
version: 2.3.1
appVersion: "1.18.4"

Always bump chart versions when:

  • template logic changes
  • value keys change
  • dependencies update

6. Rollbacks & Disaster Recovery

Helm keeps release history, allowing instant rollbacks:

helm rollback app 3
helm history app

In GitOps: rollback = git revert + automated sync.

7. Helm Best Practices for Production

  • Use values files per environment: dev, staging, prod
  • Never override values using --set in production
  • Always store rendered manifests for audit: helm template
  • Use health checks in templates (readiness & liveness)
  • Enable PodDisruptionBudgets and autoscaling via Helm
  • Validate using helm lint + kubeconform

Conclusion

Helm in production is far more than a deployment tool. With OCI registries, GitOps automation, encrypted secrets, strict versioning, and disaster recovery strategies, Helm becomes a reliable component of a modern Kubernetes platform.