Introduction

When a Helm chart depends on another chart, the parent chart can override values inside that dependency. The key is using the dependency name, or alias, as the prefix in the parent values.yaml or via --set. Once that structure is clear, nested chart configuration becomes predictable instead of trial and error.

Understand How Dependency Values Are Namespaced

Assume your parent chart declares a dependency in Chart.yaml:

1apiVersion: v2
2name: my-app
3version: 0.1.0
4
5dependencies:
6  - name: redis
7    version: 18.0.0
8    repository: https://charts.bitnami.com/bitnami

Values for that dependency live under the dependency name in the parent chart's values:

redis:
  auth:
    enabled: false

That tells Helm to render the child chart using redis.auth.enabled=false.

The same rule applies from the command line:

helm upgrade --install my-app ./my-app \
  --set redis.auth.enabled=false

If you remember only one rule, remember this one: child values are set under the child chart key.

Use the Alias If the Dependency Has One

If the dependency is declared with an alias, the alias becomes the key you must use in values.

1dependencies:
2  - name: redis
3    alias: cache
4    version: 18.0.0
5    repository: https://charts.bitnami.com/bitnami

Now the override moves from redis to cache:

cache:
  auth:
    enabled: false

That catches many people because the child chart is still redis, but the parent values key is now cache.

Inspect the Child Chart Values Before Overriding

The safest way to set a dependency value is to inspect the child chart's own values.yaml and mirror its structure under the dependency key.

For example, if the dependency defines:

1image:
2  repository: nginx
3  tag: "1.25"
4service:
5  type: ClusterIP

then the parent override must preserve that internal shape:

1mydependency:
2  image:
3    tag: "1.26"
4  service:
5    type: LoadBalancer

Guessing field names is the fastest way to end up with overrides that render successfully but do nothing.

Use global Only for Values Meant to Be Shared

Helm also supports global values, which can be read by subcharts if those subcharts are written to use them.

global:
  imageRegistry: registry.example.com

This is useful for cross-chart conventions such as image registries, pull secrets, or common labels. It is not a substitute for normal child-specific configuration. If a dependency does not read global.someKey, setting it there will have no effect.

In other words, global works only when the chart author intentionally uses it.

Verify Overrides with helm template

Do not trust a values override until you render the manifests and inspect the output.

helm template my-app ./my-app -f values.yaml

This lets you verify whether the child chart actually received the expected settings. It is especially useful when:

• the dependency uses aliases
• the child chart nests values deeply
• several values files are merged together
• a command-line --set is overriding a file value unexpectedly

Rendered output is the ground truth.

Handle Nested Lists and Special Characters Carefully

Command-line overrides become fragile when the path includes lists or values with commas and dots. In those cases, a values file is usually safer than a long --set expression.

Simple example:

helm upgrade --install my-app ./my-app \
  --set cache.master.persistence.enabled=false

Once the structure gets complex, move the override into YAML and commit it as configuration. That makes reviews easier and avoids shell escaping bugs.

Common Pitfalls

• Using the dependency package name when the parent chart declared an alias.
• Writing child overrides at the top level instead of under the dependency key.
• Assuming global values work automatically for every subchart.
• Setting a path that does not match the child chart's real values.yaml structure.
• Trusting --set blindly without checking the rendered manifests.

Summary

• Set dependency values under the dependency name or alias in the parent chart.
• Mirror the child chart's own values structure exactly.
• Use aliases consistently because they change the override path.
• Reserve global for values the child chart is explicitly built to consume.
• Validate the result with helm template before assuming the override worked.