Kubernetes Helm Values Management

Kubernetes Helm Values Management is the practice of structuring, layering, and safely overriding the parameters that flow into a chart's templates, covering the precise precedence order Helm applies when multiple values sources are combined, the global values mechanism for sharing configuration across subcharts, and the practices that keep values files maintainable as a chart grows in complexity.

Values Precedence Order

From Lowest to Highest Priority

helm install my-app ./mychart \
  -f values-production.yaml \
  --set replicaCount=5 \
  --set-string version=1.2.0

Helm merges values from several sources in a fixed precedence order: the chart's own values.yaml defaults are lowest priority, followed by any -f/--values files applied in the order given (later files override earlier ones), followed by individual --set and --set-string flags, which take precedence over everything else, including any -f file specified in the same command.

--set, --set-string, and --set-json

helm install my-app ./mychart --set replicaCount=5
helm install my-app ./mychart --set-string version="1.20"
helm install my-app ./mychart --set-json 'extraEnv=[{"name":"FOO","value":"bar"}]'

--set infers type automatically (a bare 5 becomes an integer), which can silently misinterpret a value intended to remain a string (a version number like 1.20 losing its trailing zero as a float); --set-string forces string interpretation explicitly, and --set-json allows structured, nested values to be supplied directly on the command line without constructing a temporary file.

Global Values for Subcharts

Sharing Configuration Across Chart Boundaries

# parent chart's values.yaml
global:
  imageRegistry: registry.internal.example.com
  environment: production

# subchart template referencing the parent's global value
image: "{{ .Values.global.imageRegistry }}/postgresql:15"

Values placed under the special global key are made available identically to the parent chart and every subchart, regardless of how deeply nested, providing the standard mechanism for configuration that must remain consistent across an entire chart's dependency tree (a shared image registry, a shared environment name) without duplicating that value into each subchart's own values namespace.

Subchart Value Namespacing

# parent chart's values.yaml
postgresql:
  auth:
    database: orders

Values intended for a specific subchart are nested under a key matching that subchart's name in the parent's values.yaml, and Helm automatically scopes them to that subchart's own .Values context during rendering, keeping a subchart's configuration isolated from unrelated siblings unless explicitly shared via global.

Layering Values Files by Environment

A Base Plus Environment-Specific Override Pattern

values.yaml               # chart defaults
values-staging.yaml       # staging-specific overrides
values-production.yaml    # production-specific overrides

helm install my-app ./mychart -f values-production.yaml

Maintaining one values file per environment, each containing only the specific overrides that environment needs rather than a full restatement of every value, mirrors the minimal-overlay discipline recommended for Kustomize and keeps a chart's default values.yaml the single readable reference for every parameter a chart exposes.

Avoiding Values Sprawl

Excessive Parameterization

A common maintenance problem is a chart's values.yaml growing to expose every conceivable field as an override, producing a values schema so large it becomes its own source of complexity; disciplined values management exposes only the parameters that genuinely vary across real installations, leaving structural decisions that never actually change fixed directly in the templates rather than needlessly parameterized.

Secrets in Values as an Anti-Pattern

Why Raw Secrets Do Not Belong in Values Files

# anti-pattern
database:
  password: "hardcoded-secret-in-plaintext"

Committing raw secret material directly into a values file, even one intended only for a specific environment, places sensitive data in plain text within version control history, which persists even if the value is later removed; secret values are more appropriately supplied at install time via --set combined with a secrets manager integration, via a separate, encrypted values file (using a tool such as SOPS or Sealed Secrets), or generated by a chart's own secretGenerator-equivalent template logic rather than checked in directly.

helm install my-app ./mychart --set database.password="$DB_PASSWORD"

Inspecting Effective Values

Verifying What Actually Applies

helm get values my-app
helm template ./mychart -f values-production.yaml --debug

helm get values shows the exact values Helm recorded as used for an installed release, while helm template --debug renders the chart locally with verbose output, both essential for confirming the actual effective values after several layered sources have been merged, rather than assuming correctness from any single source file in isolation.

Relationship to the Helm Package Model and Chart Structure

Values management is the parameterization discipline operating within the Chart.yaml, templates, and values.yaml structure described under Helm chart structure, and it is the mechanism through which the broader Helm package model's "values" half of the template-values-render pattern is actually authored, layered, and kept maintainable as a chart's real-world deployment complexity, spanning multiple environments and subcharts, grows well beyond a single flat values.yaml file.