Helm charts without the pain — Production Hardening — Practical Guide (Dec 2, 2025)

Helm charts without the pain — Production Hardening

Level: Experienced

As of December 2, 2025

Introduction

Helm remains the de facto package manager for Kubernetes, enabling easy deployment and management of applications through templated charts. However, deploying Helm charts in production often requires significant care to avoid common pitfalls such as security vulnerabilities, release failures, or configuration drift.

This article covers modern best practices for hardening Helm charts for production use, based largely on Helm v3 (>=v3.8) and Kubernetes 1.27 stable features.

Prerequisites

Helm client v3.8 or newer: This version and above includes important usability and security improvements, like stricter validation and improved OCI support.
Kubernetes cluster v1.23 or later: Support for newer Helm features such as server-side apply and advanced Resource policies.
Familiarity with Helm basics: Including charts, templates, values files, and releases.
Access to cluster RBAC and namespaces: To configure appropriate permissions and isolation.

Hands-on steps for production hardening

1. Use Strict Schema Validation with JSON Schema

Helm templates can become hard to maintain when incorrect or missing values cause unexpected behaviour. From Helm 3.7+, you can add JSON schemas (values.schema.json) to your charts to enforce strict value validation before deployment. This helps catch errors early.

# Example snippet of values.schema.json
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "replicaCount": {
      "type": "integer",
      "minimum": 1,
      "maximum": 10
    },
    "image": {
      "type": "object",
      "properties": {
        "repository": { "type": "string" },
        "tag": { "type": "string" }
      },
      "required": ["repository", "tag"]
    }
  },
  "required": ["replicaCount", "image"]
}

2. Leverage Helm Hooks and Test Framework Wisely

Use Helm hooks for pre-install or post-install jobs like database migrations, but avoid overusing them as hooks can complicate release management. From Helm 3.9+ the test framework supports more stable integration with CI pipelines — use helm test --cleanup to run health checks transparently.

3. Embrace Resource Limits and Pod Security Standards

Always define CPU and memory limits and requests in your templates. Kubernetes 1.27 emphasises Pod Security Admission controls, so adhere to standards like “restricted” or “baseline” policy levels to avoid privilege escalations.

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 512Mi
securityContext:
  runAsUser: 1000
  runAsNonRoot: true
  capabilities:
    drop:
      - ALL

4. Use Signed and Verified Helm Chart Repositories

By default, Helm supports OCI registries for charts. For production, enforce signing checks using helm verify to validate charts correspond with trusted signatures, preventing supply chain attacks.

5. Avoid Hardcoding Sensitive Configurations

Never embed secrets or passwords directly in the values.yaml or templates. Use external secret managers integrated via Kubernetes Secrets or tools such as HashiCorp Vault or SealedSecrets, combined with Helm Secrets plugin.

6. Adopt Immutable Tags and Image Policies

Use immutable image tags (SHA digests) instead of “latest” or floating tags to guarantee repeatable deployments. Helm does not automatically resolve digests, so bake the full image reference into values during CI pipelines.

Common pitfalls and how to avoid them

Not validating your values inputs

Without JSON schema or careful checks, bad values can break your chart rendering, causing failed or inconsistent releases. Mitigation: always include a schema and automate linting with helm lint.

Overly permissive RBAC

Charts sometimes request cluster-admin privileges unnecessarily. Overprivileged roles can lead to security breaches. Mitigation: apply the principle of least privilege by defining scoped Role and RoleBinding per namespace.

Relying on Helm upgrades for stateful apps

Applications with persistent state, such as databases, require careful upgrade strategies. Helm upgrades that delete and recreate resources can cause downtime or data loss. Mitigation: leverage Kubernetes native StatefulSets and carefully manage upgrade hooks and persistence claims.

Hardcoding environment-specific values in charts

This limits chart reusability and complicates CI/CD pipelines. Mitigation: use separate values files per environment and deploy via pipelines that inject correct configurations dynamically.

Validation

Validation is key in production readiness. Combine these tools and practices in your pipeline:

helm lint — checks chart syntax and structure
helm template — generates manifests locally to inspect output before deployment
kubectl apply –dry-run=client — simulates Kubernetes resource creation
helm test — run defined tests post installation
Security scanners — such as kube-score or Polaris on generated manifests

Checklist / TL;DR

Include values.schema.json for strict input validation (Helm 3.7+).
Set CPU/memory requests and limits in all pods.
Apply Pod Security Admission policies (K8s 1.25+ standardised).
Use OCI chart registries and verify signatures with helm verify.
Do not embed secrets; integrate external secret managers.
Use immutable container image tags (SHA digests) for reproducible deployments.
Limit RBAC to necessary scopes, avoid cluster-admin where possible.
Avoid complex Helm hook chains; keep them minimal and transparent.
Validate with helm lint and helm test, plus Kubernetes dry-runs.
Separate environment values files; avoid environment-specific defaults in your charts.

When to choose alternative tools

Helm vs Kustomize: Kustomize specialises in declarative layering and patching of Kubernetes manifests without templating, which can offer simpler change management and less templating complexity. Use Kustomize when you prefer native Kubernetes configuration without templating overhead, but it lacks Helm’s packaging and lifecycle management.

Helm vs Flux/ArgoCD: These GitOps tools complement Helm by automating chart deployments and lifecycle management, adding observability and rollback capabilities. Use Helm for manual or CI-driven deployments; integrate Flux or ArgoCD for fully automated GitOps workflows.