How would you set up and manage a private Helm chart repository for an organization's internal charts?

The most common modern approach is using an OCI-compliant container registry (the same one likely already hosting your container images — ECR, ACR, GCR, Harbor, or similar) as the chart repository, since Helm 3 supports pushing and pulling charts as OCI artifacts directly (helm push/helm pull against an oci:// reference) — this avoids standing up and maintaining a separate, Helm-specific repository server, reusing infrastructure that's likely already in place and already has established access-control and authentication mechanisms.

The core design decision is whether to reuse existing container-registry infrastructure (via OCI support) or maintain a separate, Helm-specific repository — the former is now the standard recommendation precisely because it avoids duplicating access-control and hosting infrastructure the organization likely already has.

• Charts must be versioned and retrievable by version, the same way container images are.
• Access to the repository must be controlled by the organization's existing authentication/authorization mechanisms, not a separate bespoke system.
• Publishing a new chart version should fit naturally into an existing CI/CD pipeline.

OCI registries as chart repositories are now the standard, Helm-native approach: since Helm 3.8+, OCI support is stable and doesn't require an experimental flag — helm push mychart-1.2.0.tgz oci://my-registry.example.com/charts publishes a chart version, and helm install myrelease oci://my-registry.example.com/charts/mychart --version 1.2.0 installs directly from it, without any separate "Helm repository index" concept to maintain.

This reuses existing container registry infrastructure and its access control: an organization already running a private container registry (ECR, ACR, GCR, Harbor, JFrog Artifactory) can typically use that same registry for charts too, inheriting whatever authentication (IAM roles, service accounts, registry credentials) is already configured for image access — this is a meaningful operational simplification compared to maintaining an entirely separate Helm-specific repository server with its own access control.

The older classic HTTP chart repository model (index.yaml + a static file server) still works, but requires more manual upkeep: this older approach involves hosting a static index.yaml file (generated via helm repo index) alongside chart .tgz packages on any HTTP server (S3 with static hosting, GitHub Pages, ChartMuseum) — it remains supported and is still used, particularly by projects that predate OCI support becoming standard, but requires explicitly regenerating and republishing the index file on every chart update, a manual step the OCI approach doesn't need at all.

CI/CD integration typically packages and pushes a new chart version as part of the same pipeline that builds and pushes the application's container image: helm package followed by helm push (or the older helm repo index + upload for classic repositories), triggered on a version tag or merge to a release branch, keeps chart publishing consistent with how the rest of the deployment artifacts are already built and versioned.

Semantic versioning discipline for charts matters as much as it does for the images they deploy: since consuming pipelines/teams pin or range-constrain chart versions (the same precedence and dependency-management concerns as any other versioned dependency), maintaining clear, meaningful semantic versioning for chart releases (not just bumping a version arbitrarily) is what makes version pinning and controlled upgrades actually meaningful downstream.

The OCI approach requires the org's container registry to actually support OCI artifact storage for charts specifically (not just container images) — most major registries now do, but it's worth confirming for a specific existing registry rather than assuming. The classic HTTP repository approach is simpler to stand up from scratch with minimal infrastructure (even a basic static file host works), but the manual index-regeneration step is a genuine, easy-to-forget operational burden that the OCI approach eliminates entirely.

• OCI-compliant container registries are the modern, Helm-native way to host private charts, avoiding a separate Helm-specific repository server.
• This typically reuses existing container registry infrastructure and its established authentication/access control, rather than requiring a bespoke system.
• The classic HTTP repository model (index.yaml + static hosting) still works but requires manually regenerating and republishing the index on every update.
• Integrate chart packaging/publishing into the same CI/CD pipeline that builds the application, and maintain genuine semantic versioning discipline for charts.

• Helm: Use OCI-based Registries
• Helm: The Chart Repository Guide