helm-values

Helm values merge in a defined hierarchy: built-in defaults are overridden by values.yaml, then by parent chart values, then by -f file overrides, and finally by --set flags. Each layer replaces or extends the previous one, with --set taking highest precedence. Understanding this order ensures your configuration changes apply as intended.

Use environment-specific values files (e.g., values-dev.yaml, values-prod.yaml) passed via -f flags, combined with --set for runtime overrides. This separates configuration by environment while keeping --set available for secrets and dynamic values, maintaining clean separation between chart defaults and deployment-specific customizations.

Helm validates values.yaml against values.schema.json using JSON Schema patterns. Define schema constraints in your chart's values.schema.json file to enforce required fields, types, and formats. Helm checks compliance during install or upgrade, catching configuration errors early and preventing invalid deployments.

Yes, --set-file reads entire files and embeds their contents as values, useful for certificates, keys, or multi-line configs. Pair it with --set and --set-string for flexible configuration: --set for simple values, --set-string for strings without type conversion, and --set-file for files or secrets requiring raw content injection.

Avoid storing secrets directly in values.yaml. Instead, use --set-file to reference secret files, integrate with external secret managers, or leverage Kubernetes secrets. This keeps sensitive data outside version control while allowing Helm to merge secret values into your deployment configuration safely.

Yes, Helm supports subchart-specific values under a subchart's key and global values accessible to all charts. Define global settings in the top-level values.yaml under a `global:` key, then reference them in subcharts. This enables shared configuration across parent and child charts with selective environment-specific overrides.