Dependencies and Library Charts
Compose charts from subcharts declared in Chart.yaml, and factor shared template logic into a reusable library chart that renders nothing on its own.
You rarely deploy one thing. An app needs a database, maybe a cache, maybe a message queue. Helm's dependencies let a parent chart pull those in as subcharts instead of you copy-pasting other people's charts.
Declaring dependencies
List them under dependencies in Chart.yaml with a name, a SemVer version range, and a repository (an HTTP repo, an OCI registry with the oci:// prefix, or file:// for a local sibling). Then helm dependency update resolves them and vendors the .tgz files into charts/, writing a Chart.lock so builds are reproducible.
Two flags that make dependencies pleasant
condition— a values key that toggles the whole subchart on or off (postgresql.enabled). Ship the dependency but let operators skip it when they bring their own database.- Overriding subchart values — keys nested under the subchart's name in the parent's
values.yamlflow down into it.
Library charts: DRY without deploying anything
A chart with type: library renders no resources of its own. It exists only to define named templates that other charts include. This is how you stop copying the same _helpers.tpl into twelve microservice charts — write the labels, the fullname logic, a standard Deployment skeleton once, and depend on it everywhere.
Example
# Chart.yaml -- a parent that pulls in Postgres and a shared library
apiVersion: v2
name: my-api
version: 1.4.0
appVersion: "2.3.0"
dependencies:
- name: postgresql
version: "~15.5.0" # SemVer range: allow patch bumps
repository: oci://registry-1.docker.io/bitnamicharts
condition: postgresql.enabled # toggle via values
- name: common
version: "1.x.x"
repository: file://../common-lib # a type: library chart
# library charts render nothing themselves -- included, not installed
---
# resolve + lock: helm dependency update
# reproducible build in CI: helm dependency buildWhen to use it
- A developer declares the Bitnami PostgreSQL chart as a dependency so a single helm install deploys the full application stack rather than requiring two separate install commands.
- A platform team extracts shared naming and label helpers into a library chart and declares it as a dependency in every application chart, keeping helper logic in one versioned place.
- An operator disables the bundled Redis subchart in production by setting redis.enabled: false in the production values file, because a managed ElastiCache instance is used instead.
More examples
Library chart dependency
Declares a library chart dependency so the consuming chart can use shared named templates without duplicating helper code.
# Chart.yaml of consuming chart
dependencies:
- name: common
version: "2.x.x"
repository: https://charts.bitnami.com/bitnami
# type: library (Helm infers this from the dependency's Chart.yaml)
# Use a helper from the library:
# {{ include "common.fullname" . }}Fetch and lock dependencies
Downloads subchart archives and commits the generated Chart.lock so CI builds use exact versions rather than re-resolving constraints.
helm dependency update ./myapp
# Inspect what was downloaded
helm dependency list ./myapp
# In CI: use lock file for reproducible builds
git add myapp/Chart.lock
git commit -m 'chore: lock helm dependencies'Override subchart config
Controls subchart enablement and configuration from the parent chart's values, passing settings down to the postgresql subchart.
# parent values.yaml
postgresql:
enabled: true
auth:
postgresPassword: secret
database: myappdb
primary:
persistence:
size: 50Gi
redis:
enabled: false # using managed ElastiCache in production
Discussion