Would you move your team's Helm chart distribution to an OCI registry, and what breaks if you do?

## Frame the decision, not the technology The honest answer starts by separating two populations of consumer, because they pull in opposite directions: - **Automated, internal consumers** — pipelines, in-cluster reconcilers, platform tooling — that reference exact versions. They never browse. For them a registry is close to free. - **Human, exploratory consumers** — engineers evaluating what your platform offers, and any external audience. They *do* browse, and browsing is precisely what a registry does not provide for charts. If your population is entirely the first kind, this is an easy yes. If it is meaningfully the second, the migration has a documentation deliverable attached to it, and pretending otherwise is how these projects end badly. ## What you gain **One artefact system.** The chart and the image it deploys live in the same registry, under related paths, with one set of credentials, one retention policy, one replication configuration and one audit trail. Most organisations already run a registry to a high standard; a static chart repository is usually somebody's side project. **One authentication and authorisation model.** A registry expresses per-path permissions. "This job may publish under `platform-charts/*` and nothing else" is a sentence the registry can enforce. Basic auth in front of a static file server usually cannot express that. **Publishing gets shorter.** With a classic repository, publishing is package, upload, regenerate the index, serve it, and wait for consumers to refresh their cached copy. With a registry it is one push, visible immediately. One fewer artefact to keep in sync is one fewer way to ship a version nobody can see. **Mirroring and air-gap transfer** ride on registry machinery you likely already have for images, rather than a second bespoke path for charts. ## What you lose or must rebuild **Discovery.** `helm search repo` reads cached repository indexes and a registry has none, so it silently returns nothing. Replace it deliberately: a published catalogue of supported charts and versions, and a helper that lists a path's tags. This is the item most often left out of a migration plan. **Consumer compatibility.** Every place that fetches a chart must handle `oci://`. Enumerate them: CI jobs, developer laptops, any GitOps controller such as Argo CD or Flux, and any internal tool that wraps Helm. Check each one before you retire the index, not after. **Durability assumptions.** A `.tgz` on a file server stays until someone deletes it. A registry tag lives under a retention policy that may have been written with build images in mind, where expiring anything older than ninety days is sensible. Applied to charts it can remove the version a live release was installed from — the one you need for a rollback or an audit. Decide explicitly that chart paths are exempt, and verify the rule. **Nothing about trust changes.** Provenance is still opt-in and produced at package time; pushing into a registry signs nothing for you and verifies nothing on the way in. Do not let "we moved to the registry" be recorded as a supply-chain improvement it is not. ## How to run the migration 1. **Dual-publish first.** Publish every version to both the registry and the existing indexed repository. Classic repositories are not deprecated — the documentation recommends registries, which is a weaker claim — so there is no deadline forcing a rushed cutover. 2. **Agree the path layout up front.** Where charts sit relative to images, and how that maps onto the permissions your registry can express. Renaming a published path later is worse than deciding slowly now. 3. **Migrate consumers one at a time**, starting with the ones you own. Each cutover is a small change: the reference form, and the credential the job uses. 4. **Add the catalogue before you remove the index**, so the discovery gap never actually opens. 5. **Instrument the old path.** Watch the access log on the index until it goes quiet. A silent index is the only evidence that nothing depends on it; an announcement is not. 6. **Then retire it** — and keep the archives readable for a stated period rather than deleting them the same day. ## Where you would decide otherwise Keep the indexed repository when you publish to an audience you do not control and cannot instrument, when browsability is part of the product, or when a critical consumer cannot speak `oci://` and you do not own it. "Both, indefinitely" is a legitimate steady state; the cost is one extra publish step in a pipeline you already have, which is small next to breaking a consumer you cannot see.