How do you migrate Helm chart hosting from ChartMuseum to OCI registries, and what versioning and CI/CD patterns does OCI enable that ChartMuseum cannot?
Quick Answer
OCI registries store Helm charts as OCI artifacts alongside container images, eliminating the need for a separate ChartMuseum server. Migration involves pushing existing charts with helm push to an OCI endpoint, updating Chart.yaml dependencies to use oci:// URIs, and adjusting CI pipelines. OCI enables immutable tags, multi-architecture chart metadata, and unified access control across images and charts.
Detailed Answer
Think of a company that stores its documents in a filing cabinet in one building and its photos in a separate storage room across town. Every time someone needs both, they make two trips. OCI registries are like consolidating both into a single digital vault — Helm charts live right next to container images in the same registry with the same authentication, access control, and replication policies.
ChartMuseum was the standard Helm chart repository server before Helm v3.8 made OCI registry support generally available. It runs as a separate service with its own storage backend, API, authentication, and availability requirements. OCI registries like Amazon ECR, GitHub Container Registry, Azure Container Registry, and Harbor already host container images and now support Helm charts as first-class OCI artifacts. This eliminates an entire infrastructure component and its operational overhead.
The migration workflow has several steps. First, pull existing charts from ChartMuseum using helm pull with the legacy repo URL. Then authenticate to the OCI registry with helm registry login. Push each chart version using helm push, which packages the chart and uploads it as an OCI artifact with the chart version as the tag. Update all Chart.yaml dependency entries from repository: https://chartmuseum.company.com to repository: oci://registry.company.com/charts. Update CI/CD pipelines to use helm push instead of the ChartMuseum API or the helm-push plugin. Finally, run both systems in parallel during migration, with OCI as the primary source and ChartMuseum as read-only fallback.
In production, OCI registries provide capabilities ChartMuseum lacks. Immutable tags prevent overwriting a published chart version, which ChartMuseum allowed by default and caused silent deployment drift. Registry replication across regions is built into most cloud registries, while ChartMuseum required custom solutions. Unified RBAC means the same IAM policies control who can push images and charts. Vulnerability scanning services that already scan container images can inspect chart contents in the same workflow. CI pipelines can use helm push in the same step as docker push, reducing pipeline complexity and credential management.
The non-obvious gotcha is that OCI registries do not support the helm repo index or helm search repo commands that teams may rely on for chart discovery. There is no server-side index.yaml equivalent in OCI. Teams must use helm show chart oci://registry.company.com/charts/payments-api --version 2.8.4 to inspect individual charts, or build a custom catalog using registry APIs. This changes the developer experience and may require building an internal chart catalog UI or documentation page to replace the browsable index that ChartMuseum provided.