Private Helm Chart Repository & OCI Registry

A private Helm chart repository that speaks index.yaml and OCI.

One helm-format repository, two ways in: the classic chart repository with a generated index.yaml for helm repo add, and an OCI registry for helm push and helm install oci://, with the same project and the same credentials. Signed charts keep their provenance, every version traces back to the pipeline that built it, and the charts live in the same self-hosted registry as the images they deploy.

Move consumers to OCI at your own pace, without running two registries.

OCI is where Helm is heading, but not every pipeline, tool and team moves on the same day. A helm-format repo in OrbitalReg serves both paths side by side under one project and one set of credentials. The listings stay honest: a chart pushed over OCI appears on the OCI path, a chart published to the classic repository appears in index.yaml.

Classic chart repository

# consume: index.yaml generated by the registry
$ helm repo add platform \
    https://registry.example.com/helm/acme/charts/
$ helm install web platform/web-app

# publish: ChartMuseum API, so cm-push just works
$ helm cm-push web-app-1.4.0.tgz platform

OCI registry · Helm 3.8+

# name and version read from Chart.yaml
$ helm push web-app-1.4.0.tgz \
    oci://registry.example.com/acme/charts
$ helm install web \
    oci://registry.example.com/acme/charts/web-app \
    --version 1.4.0

one helm-format repo · one project · one login · one audit log

Charts with a paper trail, next to the images they deploy.

ChartMuseum-compatible uploads

The classic path speaks ChartMuseum's upload API (POST /api/charts and /api/prov), so helm cm-push and existing curl steps in CI keep working unchanged. OrbitalReg builds and serves index.yaml itself; consumers run helm repo add and helm install as they always have.

OCI registry for Helm 3.8+

The same helm-format repo answers helm registry login, helm push, helm pull and helm install oci://… over the Docker v2 registry protocol, Helm's stable OCI path since 3.8.

Chart.yaml is the source of truth

On an OCI push the chart name and version are read from Chart.yaml, not from the command line, and the chart lands at <project>/<repo>/<chart-name>:<chart-version>. No drift between what the CLI said and what the chart declares.

Signed charts stay signed

If you package with helm package --sign, the .prov provenance file is pushed as an extra manifest layer automatically, and the repository browser marks every chart version that carries one with a provenance badge.

Back to the commit that built it

Attach a build-info record from CI and the chart's detail page shows a provenance card with source, build and signing identity, so an audit question about a release traces to a commit and a pipeline run in one click.

Governed like every artifact

Charts live under the same projects, roles, retention policies and append-only audit log as your images and packages. Promotion between repositories runs through the same gate, and security blocks and the optional pull-gate (including your own Rego rules) apply on every download path.

Sign once in CI. The registry keeps the proof.

Package with helm package --sign and push as usual: the .prov file travels with the chart as an extra manifest layer, and the repository browser badges every signed version. Add a build-info record from your pipeline and the same chart version links to its commit, CI run and signing identity. That answers "where did this release come from?" without opening a ticket.

# sign at package time; the .prov rides along on push $ helm package --sign --key 'platform-release' \ --keyring ~/.gnupg/secring.gpg ./web-app $ helm push web-app-1.4.0.tgz oci://registry.example.com/acme/charts # the repository browser now badges web-app 1.4.0 as signed

A chart is only half a release. The image is the other half.

ChartMuseum does one job, serving a classic chart repository, and does it well. OrbitalReg speaks its upload API, so moving off it is a URL change in your helm cm-push step, not a CI rewrite. Harbor took the other route: since v2.8.0 it no longer ships ChartMuseum at all, so OCI is the only Helm path there. In OrbitalReg a release's chart and the container image it deploys sit in the same registry, under the same projects, roles and audit log, and the Helm format keeps both the classic and the OCI path open. It is one GA adapter among 40+, included in the free version.

OrbitalReg itself installs from a Helm chart, listed on Artifact Hub under a verified publisher. See the install page. Coming from Artifactory's Helm repositories? The migration page covers the cutover, and every other format is on the formats overview.

Private Helm repositories, answered.

How do I run a private Helm chart repository?

Create a helm-format repository in an OrbitalReg project. Consumers either add it as a classic chart repository with helm repo add <name> https://<host>/helm/<project>/<repo>/, or log in with helm registry login and install over OCI with helm install <release> oci://<host>/<project>/<repo>/<chart> --version <x.y.z>. Both paths share the repository's project and authentication.

Classic index.yaml or OCI: which should we use?

Both are served from one helm-format repo, so you don't have to decide for everyone at once. OCI is where Helm itself is heading and needs Helm 3.8 or later; the classic index.yaml path keeps tooling and older clients working that expect a chart repository index. Note that the two listings are separate: a chart pushed over OCI is visible through the OCI path, a chart published to the classic repository through index.yaml.

We publish with helm cm-push to ChartMuseum. What changes?

Only the URL. OrbitalReg's classic Helm path accepts ChartMuseum's upload API: POST /api/charts for the chart and /api/prov for its provenance file. That means helm cm-push and curl-based upload steps keep working unchanged against an OrbitalReg helm-format repository, and charts are served at the repository root as ChartMuseum serves them.

Harbor 2.8 removed ChartMuseum. Where do our index.yaml chart repositories go?

Harbor dropped ChartMuseum from both its UI and backend in v2.8.0, which leaves OCI as the only Helm path there. If parts of your estate still rely on a classic index.yaml repository, an OrbitalReg helm-format repo serves that index next to the OCI path, so you can move consumers to OCI at your own pace instead of in one cutover.

Does OrbitalReg keep Helm chart provenance files?

Yes. A .prov file generated by helm package --sign is pushed as an extra manifest layer on the OCI path, and chart versions that carry one show a provenance badge in the repository browser. Separately, a CI build-info record links each chart version to its commit, pipeline run and signing identity.

Can we migrate Helm repositories from JFrog Artifactory?

Yes. The migration CLI maps Artifactory Helm repositories (index.yaml, chart tarballs and signed provenance) to OrbitalReg's helm format, and Helm-on-OCI repositories to its container registry. Push and pull commands stay format-native, so helm push and helm install keep working against the new host.

Is the Helm format part of the free version?

Yes. The helm format is included in every tier, including OrbitalReg Free, together with the security layer.