Written by Albert Friedman
on 

Hands-on with Helm: package and distribute your charts as OCI artifacts

Kubernetes packaging has been moving fast: Helm charts are no longer confined to index.yaml-hosted repositories. Today, storing charts as OCI artifacts in container registries is a practical, well-supported pattern that simplifies distribution, integrates with container workflows, and better fits modern CI/CD pipelines. This hands-on guide shows why OCI-based Helm charts matter, and walks through packaging, pushing, installing, and (optionally) signing charts for production use.

Why this matters now

What you’ll learn

Prereqs and quick checklist

Step 1 — create and package a chart If you already have a chart directory, skip the create step.

Create a sample chart:

helm create myapp
# edit Chart.yaml, templates/, values.yaml as needed

Package the chart into a .tgz archive (Helm uses Chart.yaml name & version to name the file):

helm package myapp
# produces myapp-0.1.0.tgz (assuming version 0.1.0 in Chart.yaml)

The packaged .tgz is what Helm will push to the OCI registry. (cloud.google.com)

Step 2 — login and push the chart to an OCI registry Authenticate your Helm client to the registry. Example: GitHub Container Registry (GHCR) or any other OCI endpoint. Helm exposes a registry login command:

# interactive password prompt
helm registry login ghcr.io -u <USER>

# or use stdin to avoid interactive prompt (example with GitHub Actions PAT)
echo $GITHUB_TOKEN | helm registry login ghcr.io -u $GITHUB_USER --password-stdin

Push the packaged chart:

helm push myapp-0.1.0.tgz oci://ghcr.io/<OWNER>/helm-charts

Helm will push the chart as an OCI artifact and print the pushed image ref and digest. The same push flow works with Artifact Registry, Harbor, ACR, GCR, etc. (help.cloudsmith.io)

Step 3 — install a chart directly from an OCI registry You don’t need to “helm repo add” for OCI charts. Install or upgrade directly using the oci:// reference:

# install a specific version
helm install myrelease oci://ghcr.io/<OWNER>/helm-charts/myapp --version 0.1.0

# or upgrade (install if missing)
helm upgrade --install myrelease oci://ghcr.io/<OWNER>/helm-charts/myapp --version 0.1.0

If the registry requires authentication, ensure you’ve run helm registry login first. Many official projects now recommend installing from their OCI registry. (Example: cert-manager points users to their OCI chart location.) (cert-manager.io)

CI/CD: automate packaging and pushing (GitHub Actions example) A common pattern is to package and publish charts on release/tag events. Here’s a minimal GitHub Actions job snippet (conceptual):

name: Publish Helm chart
on:
  release:
    types: [published]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Helm
        uses: azure/setup-helm@v3
      - name: Get tag
        id: tag
        run: echo "TAG=${GITHUB_REF#refs/tags/}" >> $GITHUB_OUTPUT
      - name: Login to GHCR
        run: echo "$" | helm registry login ghcr.io -u $ --password-stdin
      - name: Package and push
        run: |
          helm package ./charts/myapp --version $ --app-version $
          helm push myapp-$.tgz oci://ghcr.io/$/helm-charts

This pattern ties chart versions to Git tags and publishes to the same container registry you might already use for images. Real pipelines should include linting, chart tests, and security checks before publishing. Example CI patterns are used in multiple public projects and blog examples. (xenitab.github.io)

Optional: sign and verify charts for integrity and supply-chain trust

Simple cosign workflow (conceptual)

# after helm push, capture digest (helm prints it)
CHART_REF=ghcr.io/<OWNER>/helm-charts/myapp@sha256:<DIGEST>

# sign the digest (keyless or key-backed)
cosign sign $CHART_REF

# verify
cosign verify $CHART_REF

Work with your GitOps tooling to require verification on deploy (Flux and ArgoCD have verification options that can use cosign). (wiki.jmehan.com)

Migration notes and practical tips

Troubleshooting quick hits

Wrap-up — when to use OCI-distributed charts Use OCI for charts when you want:

If you maintain charts today, try a local end-to-end proof: package a chart, push to an OCI registry you control, install it on a cluster, and add a simple publish job to your CI. The commands in this article are the core steps you’ll repeat across registries; the larger work is operationalizing signing, access control, and CI tests.

References and further reading

If you want, I can: