Vendoring with helm dependency update

You listed your dependencies in Chart.yaml. Now helm dependency update actually fetches them and places them inside your chart.

Fetched subcharts land in a charts/ folder next to your templates. Helm packages and renders everything in there along with your chart.

By default each dependency is stored as a compressed .tgz archive in charts/. Helm unpacks it automatically at install and render time.

The update writes a Chart.lock file pinning the exact resolved versions and digests. It is the lockfile that makes builds reproducible.

You should commit Chart.lock to Git. Teammates and CI then resolve the very same versions instead of drifting on their own.

helm dependency build installs the versions already pinned in Chart.lock. Update re-resolves from Chart.yaml and rewrites the lock.

In CI you usually prefer dependency build. It trusts the committed lockfile, so the pipeline never silently upgrades a subchart on you.

Run helm dependency list to see each declared dependency and its status. It shows whether the charts directory matches Chart.yaml.

Update contacts each repository to download charts. For HTTP repos you may need helm repo add first so Helm can resolve an @alias.

Teams either commit the charts/ archives for offline builds, or gitignore them and rebuild from Chart.lock in CI. Pick one and be consistent.

Any time you change a version in Chart.yaml, re-run dependency update. Otherwise charts/ and Chart.lock stay stale and out of sync.

Your CI must build the exact subchart versions a teammate committed. Which command fits best?

You learned that dependency update fills charts/ and writes Chart.lock, while build replays that lock. Commit the lock for reproducible installs. 🔒