Introduction

In Helm, parent charts do not call child charts like functions. Instead, the parent passes values by placing them under the child chart's key in the parent values.yaml, or by using the special global section for values that should be visible across multiple charts.

Pass child-specific values under the child chart name

If a parent chart depends on a child chart named redis, values for that child go under the redis key in the parent chart.

1# parent-chart/values.yaml
2redis:
3  replicaCount: 2
4  image:
5    repository: redis
6    tag: "7.2"

Inside the child chart, those values are accessed normally as .Values.replicaCount and .Values.image.tag. The child does not write .Values.redis.replicaCount because Helm already scopes the child chart to its own subtree.

That scoping rule is the core idea. The parent shapes the values tree, and Helm passes the relevant branch into the child as that child's .Values.

Use global for shared values

When several subcharts need the same value, place it under global.

1# parent-chart/values.yaml
2global:
3  imageRegistry: ghcr.io/example
4  environment: staging
5
6api:
7  replicaCount: 2
8
9worker:
10  replicaCount: 1

Then any chart can read the shared values:

# child template
image: "{{ .Values.global.imageRegistry }}/my-service:1.0.0"

This is useful for shared registry prefixes, domain names, environment labels, or other settings that should stay consistent across multiple dependencies.

Example parent and child flow

Suppose the parent declares a dependency in Chart.yaml and wants to set the child service type:

1# parent Chart.yaml
2dependencies:
3  - name: metrics
4    version: 1.2.0
5    repository: "https://example.com/charts"

1# parent values.yaml
2metrics:
3  service:
4    type: ClusterIP

# child template
spec:
  type: {{ .Values.service.type }}

The child template stays clean because it reads the value as if it were local. Helm handles the wiring from the parent.

Aliases and command-line overrides

If a dependency is aliased, the alias name becomes the key that the parent uses for values. That is an easy place to make mistakes when a chart dependency was renamed for readability.

The same scoping rule applies to command-line overrides. For example, --set metrics.service.type=LoadBalancer targets the child through the parent values tree, not through some special subchart API.

What a child cannot do directly

A child chart should not assume it can read arbitrary parent values outside its own scope. That would make the chart tightly coupled and difficult to reuse. If a child needs something, expose it through its own values interface or use global deliberately.

This is an important design constraint. Good subcharts behave like reusable components with documented inputs, not like templates that reach upward into undocumented parent internals.

Common Pitfalls

• Writing parent values under the wrong key, so the child never receives them.
• Trying to access .Values.parent.someValue inside a child chart instead of using scoped child values or global.
• Overusing global for everything and turning chart configuration into a hard-to-maintain shared namespace.
• Forgetting that aliased dependencies use the alias name for values scoping.
• Failing to document the child chart inputs, which makes parent configuration brittle.

Summary

• Parent-to-child values are passed by nesting them under the child chart's key in the parent values file.
• Inside the child, those values appear as normal .Values entries.
• Use global only for settings that are intentionally shared across charts.
• Keep child charts reusable by defining explicit inputs rather than reaching into parent-only state.
• Helm value scoping is predictable once you think in terms of chart boundaries instead of template inheritance.