Introduction

Helm dependencies let one chart reuse other charts instead of copying templates into every service repository. In practice, "shared dependencies" usually means platform-wide charts for components like Redis, ingress configuration, or common template helpers that many applications consume together.

Declare dependencies in Chart.yaml

In modern Helm, dependencies are declared directly in the parent chart’s Chart.yaml.

1apiVersion: v2
2name: my-app
3version: 0.1.0
4dependencies:
5  - name: redis
6    version: 18.4.0
7    repository: https://charts.bitnami.com/bitnami
8  - name: platform-common
9    version: 1.2.3
10    repository: https://helm.company.internal

This tells Helm which child charts must be resolved before the parent chart can be rendered or installed.

Once declared, fetch them with:

helm dependency update ./my-app

That command downloads the dependencies and updates Chart.lock, which records the exact versions used.

Use Chart.lock for reproducible builds

Shared dependencies become risky when teams update them casually. If one developer runs helm dependency update and another does not, the rendered manifests can drift even when the parent chart code looks unchanged.

For reproducible builds:

1. resolve dependencies intentionally
2. commit Chart.lock
3. use helm dependency build in CI

helm dependency build ./my-app

build uses the lock file rather than resolving fresh versions again. That is important when many services rely on the same internal shared charts.

Override subchart values from the parent

A parent chart configures a dependency by placing values under the dependency name.

1redis:
2  auth:
3    enabled: false
4  master:
5    persistence:
6      enabled: true

This keeps the dependency reusable while still letting the parent chart choose environment-specific behavior.

Helm also supports global values when several subcharts need access to the same setting:

global:
  imageRegistry: registry.company.internal

Use global sparingly. It is useful for true cross-chart concerns, but overusing it makes configuration harder to reason about.

Make shared dependencies optional

Some dependencies should only be active in certain deployments. Helm supports this through condition and tags.

1dependencies:
2  - name: redis
3    version: 18.4.0
4    repository: https://charts.bitnami.com/bitnami
5    condition: redis.enabled

redis:
  enabled: false

This is a common pattern when development environments run an internal Redis chart, while production points to a managed external Redis service instead.

Know when to use a library chart

Not every shared dependency should render Kubernetes resources. If the goal is only to share helper templates, naming conventions, labels, or common snippets, a library chart is often the better choice.

Application chart:

• renders resources such as Deployments and Services
• can be installed directly

Library chart:

• provides reusable templates
• is consumed by other charts
• does not render standalone manifests on its own

Choosing the wrong type creates confusion. A shared helper chart should not unexpectedly deploy extra objects into every release.

Treat shared charts like platform APIs

When dozens of application charts depend on the same internal chart, that shared chart becomes a contract. Breaking changes ripple through the fleet quickly.

Good dependency hygiene includes:

• semantic versioning
• release notes for breaking changes
• staged rollout through a few services first
• render tests such as helm template in CI

helm template ./my-app
helm upgrade --install my-app ./my-app

Rendering before deployment is especially important when a shared chart changes labels, selectors, or default values in a way that affects resources indirectly.

Common Pitfalls

The biggest mistake is running helm dependency update casually and committing the result without reviewing the manifest impact. A shared dependency upgrade can change far more than the parent chart diff suggests.

Another issue is overriding too much of a subchart. If a parent chart has to replace most of a dependency’s behavior, that dependency is probably the wrong abstraction or needs a clearer interface.

Teams also misuse global values as a dumping ground for unrelated settings. That makes chart boundaries blurry and creates configuration coupling across dependencies that should remain independent.

Finally, do not ignore Chart.lock. Without it, repeated installs of the same chart can resolve to different dependency versions over time, which makes debugging rollout differences much harder.

Summary

• Declare shared Helm dependencies in Chart.yaml and resolve them intentionally.
• Commit Chart.lock so builds and deployments remain reproducible.
• Override subchart behavior under the dependency name and use global values carefully.
• Use library charts for shared template logic that should not render standalone resources.
• Treat internal shared charts as versioned platform contracts, not casual template collections.