What forms can the repository field of a Helm chart dependency take?

## What the field has to do Helm has to turn a dependency entry into an actual chart archive on disk. `name` and `version` say *which* chart; `repository` says *where the fetch happens*. Every form of the field is a different answer to that question, and each has a different failure mode when it is wrong. ## The classic chart repository: an https base URL A chart repository is nothing more than a web server hosting packaged `.tgz` charts plus an `index.yaml` that lists every chart, every version and the URL of each archive. When `repository` is `https://charts.example.com/public`, Helm fetches `index.yaml` from that base URL, looks for entries named `name`, chooses the highest version satisfying the constraint and downloads the archive the index points to. Two things surprise people. First, the URL is the **repository root**, not a link to a `.tgz` — pointing it at a file is a common and confusing error. Second, you do **not** need `helm repo add` for a dependency: the entry carries the location, so resolution works on a fresh machine or a clean CI runner with no local repository configuration at all. `helm repo add` matters for interactive searching and for repositories that need credentials. ## Referencing a locally added repository: @name `repository: "@platform"` (equivalently `alias:platform`) means "the repository this machine knows locally as `platform`". This is the form to use when the repository needs a username, password or a private CA, because those settings live with the locally added repository rather than in the chart. The trade-off is that the chart is no longer self-contained: anyone resolving it — including a CI runner — must have added a repository under exactly that name first, or resolution fails with nothing to look in. ## An OCI registry: oci:// `repository: oci://registry.example.com/charts` names a **registry path, not the chart**. Helm appends `name` to it and treats the chart version as the tag, so the entry above with `name: session-store` and version `3.8.1` resolves to `registry.example.com/charts/session-store` at tag `3.8.1`. Writing the chart name into the path — `oci://registry.example.com/charts/session-store` — is the classic mistake and produces a doubled path. There is no `index.yaml` in a registry, so range resolution works by listing the tags the registry exposes; if a range must be resolved, both listing permission and sane tag hygiene matter, and pinning an exact version sidesteps the issue entirely. OCI chart support has been generally available since Helm 3.8, and the old `HELM_EXPERIMENTAL_OCI` environment variable has not been needed since — writing it in 2026 dates your answer badly. ## A chart in the same source tree: file:// `repository: "file://../reranker-common"` points at a chart directory relative to the parent chart's own directory. This is how a monorepo shares an internally developed chart without publishing it anywhere. Resolution copies the local chart into `charts/`, so once the parent is packaged the archive is self-contained; but nothing checks that a `file://` dependency exists for someone who cloned only part of the tree, and a published chart that still expects a sibling directory is a broken chart. ## Empty or omitted An empty `repository` means the chart is expected to be present already under the parent's `charts/` directory — typically because someone committed the archive there deliberately. Helm makes no attempt to fetch it. This form is honest for a truly vendored subchart and confusing everywhere else, because the entry looks like a dependency that nobody can obtain. ## Choosing between them For charts you consume from outside, an `https://` base URL keeps the chart self-contained and reproducible on any machine. Use `@name` only when credentials force you to, and document which repository name must exist. Use `oci://` when your organisation has standardised on a registry for charts as well as images, remembering the path is the namespace and not the chart. Use `file://` for charts that genuinely live and version together in one tree, and reach for an empty `repository` only when you mean "this is vendored and stays vendored". ## What interviewers listen for The distinction between a repository *location* and a locally added repository *name*; that an https entry needs no `helm repo add`; and that an `oci://` reference stops one path segment short of the chart. Those three points tell an interviewer you have actually wired dependencies rather than copied an example.