OCI Helm registries: storing and deploying charts

Your team needs a reliable place to publish Helm charts so a build job or deployment controller can download the exact version approved for release. An OCI registry stores packaged artifacts using the registry standards also used for container images. Helm can publish and retrieve charts through that system instead of a traditional chart repository with a separate index file.

The chart and the application's container image are still different artifacts, even if the same registry holds both. A chart may download successfully while the image it references is missing or requires different credentials. Choose OCI distribution when your registry and deployment tools support it and it simplifies how you publish, retain and control access to packages.

Decide who publishes charts and which versions to retain

Record who publishes the chart, which registry path is trusted, how versions are promoted and whether artifacts can be overwritten or deleted. Prefer immutable references where the consuming tool supports them. Pinning the chart alone does not pin mutable image tags in its values.

1. Choose a release and record the exact chart artifact, dependency set and image references.
2. Authenticate using the identity available in the real CI runner, with pull-only permissions where sufficient.
3. Exercise the same retrieval through the chosen GitOps controller; CLI success does not prove controller credentials or OCI semantics match.
4. Test a clean runner without cached artifacts, then test an expired credential and a missing artifact.
5. Record how dependencies are resolved and promoted together.

Diagnose the layer that failed

Distinguish registry authentication, repository authorization, missing chart version, unsupported reference format and an application image-pull failure. A Helm chart can download successfully while one of its init containers cannot. Avoid copying broad registry credentials into every namespace just to mask a permissions problem.

Retention and rollback

Keep the prior chart and required images accessible for the rollback window. A release history entry is not a durable artifact mirror. Validate retention rules before relying on an old tag during an incident. Store provenance and approvals with the release record.

Some Helm documentation and integrations transition between major versions at different times. Confirm the exact CLI/controller support for OCI and digest references before adopting a command from an example. This guide describes an acceptance workflow; it does not claim a tested private-registry setup. Continue with GitOps ownership choices.