Introduction

Helm chart dependencies are designed to come from chart repositories or OCI registries, not from raw Git URLs. If you want to depend on a chart stored in Git, the usual answer is to publish that chart to a Helm-compatible repository first or to fetch and package it in a separate CI step before running Helm.

What Helm Expects in Chart.yaml

A chart dependency entry looks like this:

1dependencies:
2  - name: redis
3    version: 18.0.0
4    repository: "https://charts.bitnami.com/bitnami"

The repository field is meant to point at a chart repository, not a Git clone URL. Helm resolves dependencies through chart metadata, repository indexes, and packaged chart archives. A plain Git repository does not provide that interface by itself.

So this kind of dependency declaration is not a supported direct pattern:

1dependencies:
2  - name: my-chart
3    version: 1.2.3
4    repository: "git+https://example.com/team/charts.git"

The Correct Options

You usually have three workable choices.

1. Publish the Chart to a Helm Repository

Package the chart and publish it to a chart repository or an OCI registry. Then consume it normally:

helm package charts/my-chart
helm repo add internal-charts https://charts.example.com
helm dependency update

This is the cleanest solution because it matches Helm's native dependency model.

2. Vendor the Dependency into Your Repo

If the dependency is tightly controlled and changes infrequently, copy or mirror the dependent chart into your repository and reference it locally.

Example layout:

1parent-chart/
2  Chart.yaml
3  charts/
4    my-chart/

Then Helm can consume the vendored chart directly during packaging or install operations.

3. Fetch from Git in CI Before Helm Runs

If the source of truth must remain a Git repo, do the Git fetch outside Helm. For example:

git clone https://example.com/team/charts.git /tmp/charts-repo
cp -R /tmp/charts-repo/my-chart ./charts/my-chart
helm dependency build

This works because Helm sees a local chart after the CI job has prepared the filesystem. Git is still involved, but not through the repository field.

Why Raw Git URLs Do Not Fit

Helm dependency resolution is built around chart indexes and versions. A Git repo may contain:

• Multiple charts
• Unpackaged source only
• Branches instead of chart versions
• No repository index at all

That makes direct Git consumption ambiguous compared with a normal chart repository.

Prefer Stable Artifacts Over Source Repos

For teams using CI, the stronger workflow is:

1. Store chart source in Git
2. Package the chart during CI
3. Publish the packaged artifact to a Helm repo or OCI registry
4. Consume that published artifact as the dependency

This separates source control from deployment artifact distribution, which is usually the more reliable setup.

OCI registries are especially useful here because they let you keep Helm dependency resolution in the same artifact-oriented model as container images. Git remains the source of truth for chart source, but release consumers pull versioned chart artifacts instead of repository contents.

Common Pitfalls

• Putting a raw Git URL into repository and expecting Helm to clone it automatically.
• Treating a source repository like a chart repository even though it has no index or packaged releases.
• Fetching live source from Git during deployment instead of consuming versioned chart artifacts.
• Using local vendoring without a process for keeping the copied chart updated.

Summary

• Helm dependencies do not directly support raw Git URLs in Chart.yaml.
• Use a Helm repository or OCI registry when possible.
• If the chart lives in Git, fetch or vendor it before Helm runs.
• Publishing packaged charts is usually cleaner than pulling source during deployment.
• The repository field should point to a Helm-compatible artifact source, not to a Git clone URL.