Structuring Hierarchical Values for Environments

Implement a multi-file values strategy to override default configurations for specific environments like development, staging, and production deployments.

In this lesson, you will learn how to maintain clean, scalable configurations by adopting a hierarchical values strategy that separates default application settings from environment-specific overrides.

The Problem: Configuration Bloat

When you use a single values.yaml file for all environments, you quickly run into "configuration drift." You might find yourself duplicating settings for development, staging, and production, making it difficult to spot what actually changes between them. This increases the risk of deploying a local debugging setting into your production environment.

The Solution: Layered Values

Instead of one massive file, you should adopt a layered approach. You keep your base values.yaml as the source of truth for standard configurations (e.g., image repository, port numbers), and then create environment-specific files that only contain the delta.

For example, your folder structure might look like this:

my-chart/
├── values.yaml          # Default shared settings
├── values-dev.yaml      # Low replica counts, debug flags
└── values-prod.yaml     # High replica counts, resource limits

In your values-dev.yaml, you only define the values you need to change:

replicaCount: 1
resources:
  limits:
    cpu: 100m

Applying the Strategy

When you run your Helm install or upgrade command, you stack these files. Helm processes them in order, where files specified later in the command override the ones specified earlier:

helm upgrade --install my-app ./my-chart \
  -f values.yaml \
  -f values-prod.yaml

By defining the hierarchy this way, your values.yaml acts as the blueprint, and your values-prod.yaml acts as the specific instructions for that cluster. This keeps your production configuration explicit, readable, and—most importantly—easy to audit before deployment. It also prevents "magic values" from being hidden inside your templates, as every deviation from the default is clearly captured in a dedicated file.

Key Takeaway: By layering environment-specific values on top of a common base, you ensure that your production configurations remain explicit, auditable, and free from dangerous duplication.