Repositories and OCI Distribution

Classic HTTP chart repositories vs modern OCI registries (ECR, GHCR, ACR, GAR, Harbor). Pushing, pulling, and installing charts as OCI artifacts.

Overview

From chart repositories to OCI registries

Helm chart distribution has evolved from a custom HTTP-based index/archive format (classic chart repositories) to modern OCI registries. OCI (Open Container Initiative) registry support was added in Helm 3.8 and reached GA status. Today it is the recommended distribution method for Helm charts.

> [!IMPORTANT] OCI is the recommended path for new distribution: your existing container registry becomes the chart repository.

Classic chart repositories

Classic repositories serve an index.yaml file and .tgz chart archives over HTTP. You add them with helm repo add, search with helm search repo, and install with bitnami/postgresql syntax. They need dedicated hosting and separate tooling to generate and publish the index.

OCI registries

Any OCI-compliant registry stores Helm charts alongside container images with no extra infrastructure. Charts are pushed with helm push and installed with the oci:// scheme directly, with no helm repo add step.

Amazon ECR, Azure Container Registry, Google Artifact Registry — Cloud-native registries, same IAM as images
GitHub Container Registry — Natural fit for GitHub organizations
Harbor, Docker Hub, JFrog Artifactory, Cloudsmith — Self-hosted or SaaS alternatives

What OCI unlocks

Immutable references by digest — sha256:abc123 guarantees supply chain integrity
Unified access control — Same IAM and token mechanisms as container images
Provenance — .prov files upload automatically as additional OCI layers, enabling signature verification
Zero extra infrastructure — ECR, GHCR or ACR becomes the chart repository for internal charts

> [!TIP] For platform teams distributing internal charts, start from the registry you already run for images.

Key concepts

OCI (Open Container Initiative) registry: Container registry standard that Helm 3.8+ uses to distribute charts. Any OCI-compliant registry can store Helm charts. No index.yaml needed; no separate hosting infrastructure required. Charts are stored as OCI artifacts with Helm-specific media types.
helm registry login: Authenticates Helm to an OCI registry. Credentials are stored in ~/.config/helm/registry/config.json (same credential format as Docker). Must be run before helm push or helm pull from private registries.
oci:// scheme: The URL scheme for OCI registry references in helm install, helm pull, helm show. Example: oci://ghcr.io/myorg/charts/mychart. No helm repo add step — the registry is referenced directly in the command.
Digest-based installation: helm install myapp oci://registry/chart@sha256:abc123 installs an exact, immutable chart version. Unlike a version tag that can be moved, a digest reference is cryptographically bound to the exact bytes of the chart artifact. Use for production environments where supply chain integrity is critical.
Provenance file (.prov): A GPG/PGP signature file automatically uploaded alongside a chart when using helm push with provenance. Recipients verify with helm pull --verify. The .prov file is stored as an additional OCI layer with its own media type.

When to use it

Distributing charts internally across teams: push to the org's existing container registry (GHCR, ECR, ACR) using OCI
Public chart distribution: push to Docker Hub or GitHub Container Registry via OCI
Supply chain security: use digest-based installation and provenance verification for production environments
Classic repos: when your tooling (older Argo CD, older Helm versions) does not support OCI; helm-chartmuseum is the standard self-hosted solution

Interview questions

Compare classic Helm chart repositories with OCI-based distribution.
How do you set up a chart distribution pipeline for an internal platform team?
How does OCI digest-based installation improve supply chain security?
What are the key commands for working with OCI-based Helm charts?