Overriding Values: Customizing a Release

The Layering System

One of Helm's most powerful features is its values override system. Values are applied in layers, with later layers taking precedence over earlier ones:

1. Chart defaults — the values.yaml file inside the chart itself. These are the "factory settings."
2. User-supplied values files — passed with -f or --values. You can pass multiple files; later files override earlier ones.
3. Individual overrides — passed with --set on the command line. These have the highest precedence.

An install command can stack all three layers at once — the chart's own defaults, an environment-specific values file, and a one-off --set override for something like an image tag — with each layer winning over the one before it.

When to Use -f vs. --set

Use -f with a values file for any configuration that should be version-controlled and repeatable — environment settings, resource limits, feature flags. Use --set sparingly, for truly one-off overrides like a specific image tag during a deployment pipeline run. Avoid using --set for secrets — the values end up in your shell history.

Sensitive Values

Never put plaintext secrets in values.yaml files that get committed to source control. Common patterns for handling secrets with Helm include:
- Using --set to inject secrets from a CI/CD secret store at deploy time (values are not stored in git, but are stored in the Helm release Secret in the cluster).
- Using the Sealed Secrets or External Secrets Operator to manage secrets as Kubernetes resources separately from Helm.
- Using Helm's integration with Vault via the vault-secrets-operator.