Introduction

Passing data between Helm charts is usually a values-design problem, not a runtime communication feature. Charts do not directly call each other during template rendering, so shared data must come from parent values, dependency wiring, or external Kubernetes resources. A clean contract for value names is the difference between stable releases and hard-to-debug overrides.

Understand Helm Data Flow First

Helm renders templates using a values tree and chart metadata. If chart A and chart B are dependencies of a parent chart, they can both receive configuration from that parent. This is the normal way to share data.

Key point:

• data flow is top-down from parent to subcharts.
• sibling charts do not read each other directly during render.
• shared keys should be intentionally named and documented.

A parent chart keeps ownership of integration values, while each subchart remains independently deployable.

Pattern 1: Parent Overrides Subchart Values

Suppose web chart needs URL of api chart. Put both charts under one parent and define values centrally.

1# parent/Chart.yaml
2apiVersion: v2
3name: platform
4version: 0.1.0
5dependencies:
6  - name: api
7    version: 1.2.0
8    repository: file://../api
9  - name: web
10    version: 1.5.0
11    repository: file://../web

1# parent/values.yaml
2api:
3  service:
4    port: 8080
5
6web:
7  backend:
8    host: api
9    port: 8080

The web chart consumes only web.backend.host and web.backend.port. It does not need to know where those values came from.

1# web/templates/configmap.yaml
2apiVersion: v1
3kind: ConfigMap
4metadata:
5  name: {{ include "web.fullname" . }}
6data:
7  BACKEND_URL: "http://{{ .Values.backend.host }}:{{ .Values.backend.port }}"

Pattern 2: Use global for Cross-Chart Settings

For shared keys used by multiple subcharts, global is often cleaner.

1# parent/values.yaml
2global:
3  domain: internal.example
4  environment: staging
5
6api:
7  ingress:
8    enabled: true
9
10web:
11  ingress:
12    enabled: true

In any subchart:

1{{- if .Values.global.environment }}
2metadata:
3  labels:
4    env: {{ .Values.global.environment | quote }}
5{{- end }}

Use this sparingly. If everything is placed under global, chart boundaries become blurry and upgrades become riskier.

Pattern 3: Pass Computed Values from Parent Templates

Sometimes parent chart computes names and injects them into child values files through explicit values, not direct template execution inside child values.

A practical method is to keep naming conventions deterministic. Example: service host equals release-scoped fullname.

1# parent/values.yaml
2web:
3  backend:
4    host: "{{ .Release.Name }}-api"

This string in values.yaml is not templated automatically. If you need dynamic evaluation, you must render with tpl inside chart templates where appropriate.

1# web/templates/configmap.yaml
2{{- $host := tpl .Values.backend.host . -}}
3apiVersion: v1
4kind: ConfigMap
5metadata:
6  name: {{ include "web.fullname" . }}
7data:
8  BACKEND_HOST: {{ $host | quote }}

Use tpl carefully and only where needed because it adds complexity and can hide value-source bugs.

Pattern 4: External Resource Bridging

If charts are installed separately, share data through Kubernetes resources such as ConfigMap or Secret, then read those resources in both charts.

1apiVersion: v1
2kind: ConfigMap
3metadata:
4  name: shared-settings
5data:
6  API_BASE_URL: "http://api.default.svc.cluster.local:8080"

Each chart then references shared-settings through env vars or mounted files. This is safer than trying to create implicit chart coupling.

Validation Workflow

Use predictable checks before deployment:

helm dependency update ./parent
helm template ./parent -f ./parent/values.yaml
helm lint ./parent

Inspect rendered output for both subcharts. Confirm values arrive in expected resources and names are stable across release names and namespaces.

Common Pitfalls

• Expecting one subchart to directly inspect another subchart templates during render.
• Overusing global and losing ownership boundaries.
• Putting templated strings in values files without using tpl where required.
• Renaming value keys without updating all dependent charts and docs.
• Skipping helm template checks before cluster deploy.

Summary

• Helm value sharing is parent-driven, not peer-to-peer.
• Use parent overrides for explicit integration data.
• Use global only for truly shared cross-chart keys.
• Use tpl carefully when dynamic strings must be rendered.
• Validate rendered manifests in CI to catch value contract regressions early.