chart-releaser turns a GitHub repository into a Helm chart repository

Three moving parts, and one of them is optional

The tool is called cr, and the README describes it as helping turn GitHub repositories into Helm chart repositories by adding Helm chart artifacts to GitHub Releases named for the chart version and then creating an index.yaml file for those releases that can be hosted on GitHub Pages or elsewhere. The command list in the help output makes the structure obvious. There is package to package Helm charts, upload to upload the packages to GitHub Releases, index to update the repo index.yaml for a given GitHub repo, and push to push chart packages to an OCI registry. The first three are the classic GitHub Pages chart repository model. The fourth is newer and points at where the ecosystem has moved, since OCI registries let a chart be addressed as an image reference and remove the need for an index file at all. Everything is also available through a completion command for shell autocompletion and a version command.

Installing cr, including the container that CI actually uses

There are three documented install routes and a fourth for continuous integration. The recommended one is to download a preferred asset from the releases page and install it manually. Homebrew works through a tap.

$ brew tap helm/tap
$ brew install chart-releaser

Contributors can install from source.

// clone repo to some directory outside GOPATH

$ git clone https://github.com/helm/chart-releaser
$ cd chart-releaser
$ go mod download
$ go install ./...

And for CI there is a Docker image pushed to the helmpack/chart-releaser repository on Quay, built on top of Alpine with cr as the default entry point. The Dockerfile in the repository is small and does something worth copying, which is to run cr --help during the image build so that a broken binary fails the build rather than the pipeline that uses the image.

The upload command is where the release policy lives

Upload scans a path for chart packages and creates releases in the specified GitHub repository, uploading the packages as it goes. The flag list is where most of the operational decisions are made. The commit flag targets a specific commit for the release. The release name template is a Go template for computing release names from chart metadata and defaults to the chart name and version joined by a dash. The release notes file is a Markdown file with the chart release notes, and if it is set to an empty string or the file is not found, the chart description is used instead, which is a sensible fallback. There is a skip-existing flag to avoid re-uploading a release that is already there, a pre-release flag, a make-release-latest flag that defaults to true, a generate-release-notes flag that asks GitHub to write the name and body, and a packages-with-index flag for hosting the package files in the GitHub Pages branch. The GitHub base URL and upload URL flags exist for private GitHub, and the owner, repo and token flags identify the target.

Push to an OCI registry, with provenance carried along

The push command pushes every chart package found under the package path to an OCI registry as registry-url, chart-name, chart-version. Sibling provenance files with a .tgz.prov suffix, produced by cr package with the sign option, are pushed automatically, so signing is not a separate manual step. The credential handling is worth noting because it is the kind of detail that causes failures in CI. The username and password flags are also readable from the CR_USERNAME and CR_PASSWORD environment variables, and if neither is provided the tool falls back to the registry credentials store at ~/.docker/config.json, which is what helm registry login or docker login populates. The TLS flags cover the private registry cases, with a ca-file to verify the certificate, cert-file and key-file for client certificates, insecure-skip-tls-verify and plain-http for the cases where you know better, and a skip-existing flag to avoid pushing a version that already exists.

Dependencies are your problem, and the README shows the fix

One gap is called out explicitly. The releaser tool will not automatically add repositories for dependencies, and this needs to be added to your pipeline before running the releaser, with a linked example from another project. The example workflow adds the dependency repositories first and then runs the chart-releaser action.

    - name: add repos
        run: |
          helm repo add bitnami https://charts.bitnami.com/bitnami

      - name: Run chart-releaser
        uses: helm/[email protected]
        with:
          charts_dir: config/helm-chart
        env:
          CR_TOKEN: "${{ secrets.GITHUB_TOKEN }}"

The order matters, since the chart packages are packaged against a repository that has to exist in the local Helm configuration first. The action takes a charts_dir and receives the token through an environment variable named CR_TOKEN, and the token is the repository's own GitHub token. This is the part of the setup that is easy to get wrong, since the failure appears as a packaging error rather than a permissions error.

What chart-releaser does not do for you

The scope is narrow in a useful way, and the limits follow from it. There is no signing by default, since the provenance files come from cr package with the sign option and the upload command does not mention invoking it, so a policy of signing every chart is something you configure. There is no multi-repository index, because the index command is scoped to a given GitHub repo, so if you want one index listing charts from several repositories you are combining artifacts yourself. There is also no support for a chart that does not follow the expected layout, since the tool works on packages rather than on a chart directory, and the package command is the entry point for that. The maintainer cadence is worth noting too. The tags are v1.8.1 and v1.8.0, both from 2025-06-02, then v1.7.0 from 2024-12-18, and the last push was on 2026-10-17, so the tree is being worked on while the release line has not moved since the middle of 2025. For a tool whose whole job is to be run in CI, that is a factor to weigh against the fact that the interface is a stable set of flags.

Editorial conclusion

chart-releaser suits a project that wants to publish its own Helm charts without standing up a chart repository server, because a GitHub repository with Releases and a Pages branch is enough and most teams already have both. It is the wrong tool for a team that wants a curated, single index across many charts in one place, since a repository index is per repository, and it is the wrong tool if you want provenance without the extra work, because signing has to be arranged separately. Before adopting it, read the section on chart dependencies, since the tool does not add dependency repositories for you and that has to be in your pipeline, and check the release name template behaviour if your chart versions do not map cleanly onto GitHub release tags. The last push was on 2026-10-17 and the current release is v1.8.1 from 2025-06-02.

Frequently asked questions

Official sources

1. helm/chart-releaser on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases