How do you choose between publishing your Helm charts to a static index.yaml repository and to a registry?

This is a distribution-channel decision, not a chart decision, and framing it that way removes most of the noise from the argument. ## What does not change The packaged chart is identical. `helm package` produces a `.tgz` that either channel carries unmodified; nothing in `Chart.yaml` names a destination, and a chart is not rebuilt or converted to move channels. So the choice cannot be made on chart-authoring grounds at all - it is made on hosting, identity, discovery and mirroring. ## What each channel actually is **Static repository.** A directory of tarballs plus a generated `index.yaml` behind an HTTP URL. There is no service to operate, patch or scale; availability is your object store's availability. The catalogue is one file that lists every version of every chart in the repository, and every client downloads that file whole each time it refreshes. Publishing is a file copy plus a regeneration of the index, which is state you must not corrupt or race on. Access control is whatever the web host offers, which typically means a shared credential rather than per-team identity. **Registry.** Charts are pushed as artefacts alongside images, and inherit the platform you already run for images: the same login, the same per-repository access rules, the same replication between regions or into restricted networks, the same retention and immutability settings if the product supports them. There is no catalogue file, so there is nothing equivalent to searching a repository index; discovery has to come from a portal, documentation, or the registry's own listing API. Consumers reference charts by `oci://` rather than by a repository alias, which is the part that touches every pipeline, values file and controller definition you own. ## The four questions I actually ask **What already exists?** Most organisations already run a registry with authentication, quotas, replication and someone on call for it, and do not run a chart repository at all. Putting charts on the path images already take usually removes more operational surface than it adds, and it unifies the answer to "who may publish" and "who may pull". **What fetches the charts?** In-cluster reconcilers, delivery pipelines and infrastructure tools all need to understand the reference form and hold credentials for it. This is a concrete inventory exercise, not a philosophical one: every consumer of a chart is a place that has to change, and one that cannot is a hard constraint on the timeline rather than an argument against the destination. **How do artefacts cross boundaries?** For an air-gapped or restricted enclave, a static repository mirrors as a file copy - sync the tarballs, regenerate the index with the internal base URL so entries point inside the enclave. A registry mirrors with the registry-to-registry copy the platform already performs for images, which usually already crosses that boundary under review. Whichever path is already trusted and audited tends to decide this. **How big is the catalogue?** With one chart and 63 versions, the index file is trivial. With a few hundred charts and years of versions it becomes a multi-megabyte file that every client, every CI job and every developer machine pulls on refresh - a real cost, and one that grows monotonically because you never delete published versions casually. A registry has no equivalent per-refresh whole-catalogue download. ## Two arguments I do not accept "Classic repositories are deprecated." They are not. The documentation recommends the registry path, and the tool supports both; "deprecated" is a claim someone should be asked to substantiate. "Moving to a registry fixes trust." It does not sign anything, does not make versions immutable by itself, and does not stop a bad chart from being pulled. Those are separate decisions that happen to be easier to enforce where a platform already has the hooks - which is a reason, but a different reason, and conflating them produces a migration that claims security benefits it did not deliver. ## Dual publishing Publishing the same tarball to both channels is a reasonable migration state: it lets consumers move at their own pace. It must be one step that fails the build if either upload fails, one channel must be declared authoritative for what "released" means, and it needs an end date. Left alone it becomes two catalogues that drift, and the failure mode is a version present in one and absent in the other with no way to tell which is correct.