Dependencies & Repositories

Each dependencies entry declares one subchart the chart bundles: name is the chart to fetch, version is a SemVer range the fetched chart must satisfy, and repository says where to fetch it from. Optional fields such as alias refine that.

An oci:// reference is a registry path whose last segment is the chart name and whose tag is the chart version. Commands take the whole path; a Chart.yaml dependency puts the path without the chart name in repository, and the chart name in name.

Collect the packaged .tgz files in one directory, run helm repo index on that directory to generate index.yaml, and serve the directory over HTTP. A chart repository is static files - no chart-server software is required.

helm repo add saves a name-to-URL entry in your local repositories.yaml and downloads that repository's index.yaml into a cache directory. Helm resolves chart names from that cached copy and never refreshes it on its own, so a version published after your last helm repo update is invisible.

The parent sets a subchart's values under a top-level key named for that dependency, or for its alias when the dependency declares one. Those parent values override the subchart's own values.yaml defaults.

helm dependency update re-resolves the ranges in Chart.yaml, rewrites Chart.lock and refills charts/. helm dependency build ignores the ranges and fetches exactly what Chart.lock already pins, so pipelines run build and authors run update deliberately.

global is a reserved top-level values key that Helm copies into every chart in the dependency tree. Parent, subcharts and grandchildren all read the same values at .Values.global, at any depth.

Chart.lock records the exact subchart versions Helm resolved from the ranges in Chart.yaml, each with its name, repository and version. The digest field hashes those dependency declarations; generated is the timestamp of the resolution.

A dependency's condition path is looked up in the values the release is rendered with, addressed from the top of that tree. Setting enabled: false inside the subchart's own values.yaml, or under the wrong key, leaves the path unresolved - and an unresolved path is ignored silently, so the subchart renders.

A Helm dependency's repository can be an https chart-repository base URL, an oci:// registry path that Helm appends the chart name to, a file:// path to a chart in the same tree, an @name reference to a locally added repository, or empty when the chart is already vendored under charts/.

Run helm registry login against the registry host, optionally reading the password from standard input. Helm writes the credential into its own registry config file, named by HELM_REGISTRY_CONFIG, and every later oci:// operation against that host uses it. helm registry logout removes the entry.

helm pull downloads a chart's packaged .tgz from a repository to the local filesystem without touching a cluster, with --version selecting an exact published version instead of the newest. Pull when you need to inspect, diff, mirror or vendor the exact artefact rather than install it.

Write the dotted path down the dependency tree from the top-level chart: --set worker-gpu.encoder.threads=12. Each segment is a dependency's name — or its alias — and --set global.x=y reaches every chart at once.

They are deleted. On upgrade Helm compares the previous revision's stored manifest with the newly rendered one and removes what disappeared, so a disabled subchart takes its objects - including any it rendered to hold data - with it. Only helm.sh/resource-policy: keep spares one.

It stops paying off once the services in it stop sharing a lifecycle. One umbrella means one release, one revision and one rollback, so every team's change deploys everything, one failing subchart fails the whole upgrade, and the single stored release record keeps growing.

Always commit Chart.lock. Commit the charts/ tarballs only when you need a build that fetches nothing and survives an upstream repository disappearing, accepting binary blobs in review, repository growth, and drift that Helm will not detect at install time.

helm search repo reads cached index.yaml files from repositories added with helm repo add, and a registry has neither an index nor a repository entry. Discovery has to come from the registry's own tag listing, from a catalogue you publish, or from versions pinned in Chart.yaml.

Nothing in Helm enforces it, but every consumer treats chart name plus version as an identity: cached indexes, pinned dependencies and stored release records all resolve by version. Overwriting makes one coordinate mean two different things. Bump the version instead.

Use --username and --password for basic auth, --ca-file to trust an internal CA, and --cert-file/--key-file for client certificates. Helm writes those credentials in plaintext into repositories.yaml, so on shared or CI machines pass them per-command with --repo instead of persisting them.

Chart.lock pins only which subchart versions are fetched, not their bytes. Reproducing a render also means fixing the parent chart artefact, the values files, image references, the Helm CLI version and the cluster API versions the render assumes.

Usually yes for internal charts consumed by automation: one artefact system, one credential model, no static index to regenerate. The costs are lost search and browsability, every consumer needing oci:// support, and registry retention now able to remove a chart a static file server would have kept.

Both channels ship the identical .tgz, so decide on operations, not features: a static index is one file on any web host carrying the whole catalogue; a registry reuses the credentials, replication and retention you already run.

Use Helm's global block only for facts that belong to the installation itself — registry mirror, storage class, cluster domain — and that most subcharts genuinely read. Everything else is cheaper duplicated per subchart, where it diffs cleanly and its blast radius is one chart.

A dependency's tags list in Chart.yaml is matched against a top-level tags map in the release's values. If any of its tags is true the dependency is enabled; if every tag it names is present and false it is disabled; if none is set it stays enabled. A resolved condition always overrides tags.

alias gives a dependency a different name inside the parent chart, which is what lets the same chart be declared twice in one Chart.yaml. Helm then treats each entry as a separate subchart named by its alias, with its own values key.

helm push takes an already-packaged .tgz and a base registry path. The chart name and version come from Chart.yaml inside the archive, not from the command, so the destination omits both. If a matching .prov file sits beside the .tgz it is uploaded alongside automatically.

helm repo index builds index.yaml from only the packages present in the directory. --merge folds an existing index.yaml into that result, so versions whose tarballs are not in that directory keep their entries instead of disappearing.

helm search repo searches only the cached indexes of repositories you have added, works offline, and returns coordinates you can install immediately. helm search hub queries Artifact Hub over the network across thousands of public repositories and returns listing pages you cannot install from until you add the repository.

import-values, listed on a dependency in Chart.yaml, copies values upward from the subchart into the parent's values — either a block the child publishes under exports, or an explicit child path mapped to a parent path.