In a Helm chart's dependencies, what does the alias field do?

## The problem alias solves A parent chart addresses its subcharts by name: the values key, the `.Subcharts` lookup and the directory identity all key off it. That means two dependency entries with the same `name` are indistinguishable, and you cannot bundle the same chart twice — which is exactly what you want when one umbrella needs, say, a public and an internal instance of the same third-party ingress-controller chart, or a recommendation re-ranker deployed once for live traffic and once for shadow scoring. `alias` gives each entry a distinct name inside this parent: ```yaml dependencies: - name: ingress-controller version: "4.13.2" repository: https://charts.example.com/public alias: ingress-public - name: ingress-controller version: "4.13.2" repository: https://charts.example.com/public alias: ingress-internal ``` ## What the alias actually renames Helm still fetches the chart called `ingress-controller` — `name` and `repository` continue to describe *what to pull*. The alias applies afterwards: each entry is presented to the rendering engine as its own subchart whose name is the alias. Three visible consequences follow. First, **the values key is the alias**. The parent addresses each copy under `ingress-public:` and `ingress-internal:` rather than under the chart's real name, and a `--set` path or a `-f` file uses those keys too. Second, **`.Subcharts` is keyed by the alias**, so a parent template that reaches into a child does so by alias. Third — and this is the one that matters operationally — **`.Chart.Name` inside that copy's templates is the alias**. Nearly every conventional chart derives object names from a helper built on the release name and the chart name, so the two copies naturally produce different Deployment, Service and ConfigMap names without you renaming anything by hand. That is the whole reason aliasing usually works at all. ## What alias does not do Aliasing is a naming device, not an isolation boundary. Both copies are the same chart rendering into the same release and the same namespace, so anything the chart names *fixedly* collides: - **Cluster-scoped resources** — a ClusterRole, ClusterRoleBinding, IngressClass or webhook configuration with a fixed name is rendered twice with the same name. In one release that is a duplicate-resource error at render or apply time; worse, if the two copies were tuned differently, whichever wins silently misconfigures the other. - **CustomResourceDefinitions.** A chart shipping CRDs in `crds/` installs them once and never templates them, so aliasing does nothing there — and it does not want to, since two copies must share one CRD. - **Anything with an override that fixes the name.** If someone sets a full-name override on both copies, or the chart hardcodes a name rather than deriving it, the alias buys nothing. - **Shared singletons the chart assumes.** Two ingress controllers in one namespace may both claim the same default class or the same leader-election lock; the collision is in the cluster, not in Helm. So the review question for any aliased dependency is: *what does this chart create whose name does not vary with the release and chart name?* Anything on that list needs an explicit override on at least one copy. ## Alias versus two releases The alternative is simply installing the chart twice as two independent releases with different release names. That gets you distinct object names for free, independent upgrades, independent rollbacks and independent failure — one copy can be upgraded at 09:00 and the other at 11:00. Aliasing inside one umbrella gets you the opposite: one command, one revision, one rollback covering both copies, and shared values through the parent. Choose aliasing when the two copies are genuinely one unit that should move together and share configuration — a pair of gateways front-ending the same platform, say. Choose two releases when the copies belong to different owners, different change cadences or different blast radii. The default answer for two instances of a third-party chart is usually two releases; the alias is worth reaching for when the umbrella already exists and the two instances are part of what it means. ## What interviewers listen for That you know why the field exists at all (name collision), that you can name what the alias renames, and — the senior half of the answer — that you immediately ask what the chart creates with a fixed name before assuming two copies can coexist.