opentelemetry-helm-charts ships signed charts, and the signing step is the hard part

One repository for the whole OpenTelemetry component set

The opentelemetry-helm-charts repository contains Helm charts for the OpenTelemetry project, and the primary language is listed as Go Template, which is what the chart templates are written in. The homepage is opentelemetry.io and the licence is Apache 2.0.

The README documents four charts in prose. The OpenTelemetry Collector chart installs the Collector in a Kubernetes cluster. The OpenTelemetry Demo chart installs the OpenTelemetry Demo. The OpenTelemetry Operator chart installs the Operator. The OpenTelemetry eBPF Instrumentation chart installs the eBPF instrumentation.

The Makefile tells a longer story, and the difference matters. The CHARTS variable there lists seven entries: opentelemetry-collector, opentelemetry-operator, opentelemetry-demo, opentelemetry-ebpf, opentelemetry-kube-stack, opentelemetry-target-allocator and opentelemetry-ebpf-instrumentation.

So the prose in the README is a partial list. The kube-stack chart, which installs the Operator plus the Collector in one go, and the target-allocator, which manages Collector replicas, are both in the repository and both omitted from the README's chart descriptions. If you are looking for the target allocator or the combined stack, the Makefile tells you they exist and the charts directory tells you where they live.

Each chart also links to a directory in the repository holding its own documentation, which is where the component specific detail lives.

Adding the repository, and finding the charts

Helm must be installed to use the charts, and the README sends you to Helm's own documentation for that. Once Helm is set up, the repository is added with a single command.

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

After that, the README says you can run a search against the repo name to see the charts, and the package is also published to Artifact Hub, with a badge linking to the package search for the opentelemetry-helm repository, so the charts are browsable in a catalogue as well as from the command line.

This is a conventional Helm repository layout, hosted as a GitHub Pages site, and the install path is the standard one. There is no operator or agent of its own to deploy, and nothing in the repository runs on your cluster until you run helm install yourself.

The repository also has an artifacthub-repo.yml file at the top level, which is the metadata Artifact Hub reads, plus a ct.yaml, which is the chart testing configuration used by the chart testing tool, and a .pre-commit-config.yaml. The pre-commit setup is a sign of a project that expects changes to go through the same checks locally as in CI.

Every chart is signed, and verifying one needs a legacy keyring

This is the part of the README that trips people up, and it is worth walking through slowly.

All charts in the repository are signed, and the README points at Helm's provenance documentation for the general process. Then it states a hard requirement: a local running gpg agent is mandatory.

The key is imported from the repository's own published key file.

curl https://open-telemetry.github.io/opentelemetry-helm-charts/pubkey.gpg | gpg --import

And then comes the wrinkle. Helm reads a legacy GnuPG keyring, which modern GnuPG, version 2.1 and later, does not create on import. Depending on your GnuPG version, you may need to export the imported key so that Helm can find it.

gpg --export > ~/.gnupg/pubring.gpg

Without that export, the key is in your modern keybox but not in the file Helm looks for, and verification fails in a way that looks like a signing problem rather than a keyring format problem.

With the key in place, you can use the --verify flag during helm install to enable chart signature validation. The README is careful to say enable, which is the right word, because the flag is opt in. A team that adds the repository and installs without the flag gets the charts and none of the integrity checking, and probably will not notice.

The requirement for a running gpg agent is the part people forget. The agent is what does the signing and the verification work, and without it the import does not complete properly.

Chart versions move with the upstream applications

The Makefile shows how the charts relate to the upstream OpenTelemetry repositories, and it is a useful map of the whole arrangement.

Three app versions are extracted from Chart.yaml files with a sed expression, one for the operator, one for the kube stack, and one for the demo. The operator app version is then used to build a URL pointing at a featuregate.go file in the open-telemetry-operator repository at the matching tag. The demo app version is used to construct URLs for the demo's VCR cassettes, for its PostgreSQL init.sql, and for the Grafana dashboard files in its provisioning directory.

In other words, the charts pin the application version, and the build then fetches the matching fixtures, initialisation SQL and dashboards from the upstream repository at that same version.

The KUBE_VERSION variable defaults to 1.29, and the CHARTS variable can be overridden on the command line, and the generate-examples target loops over the charts running helm dependency build on each and then assembling the examples directory.

The recent releases show the pace. opentelemetry-operator-0.126.1 and opentelemetry-ebpf-instrumentation-0.15.2 both on 2026-10-19, and opentelemetry-kube-stack-0.25.0 on 2026-10-16. So the operator is on a 0.126 line, the eBPF instrumentation on 0.15, and the kube stack on 0.25, all moving independently and all moving fast.

That independence is the operational point. There is no single version of OpenTelemetry to pin here, and an upgrade of one chart does not move the others.

Who maintains it, and the governance behind the names

The README lists the maintainers and, unusually for a charts repository, links the definition of each role to the OpenTelemetry community repository.

The maintainers are Dmitrii Anoshin of Splunk, Jacob Aronoff of Tero, and Tyler Helmuth of Grafana Labs. The approvers are Alex Birca of Adobe, Jared Tan of DaoCloud, Juliano Costa of Datadog, Povilas of Coralogix, and Cyrille Le Clerc of Datadog. There is one triager, Marc Schäfer. And there is an emeritus section naming people who previously held the roles, including Tigran Najaryan as a maintainer and three former approvers, with a link to the community repository for the emeritus role definition.

The link structure matters more than it looks. Each role points at a guide in the open-telemetry/community repository, which means the chart repository inherits the wider OpenTelemetry project's governance rather than defining its own. The people listed are the same names that would appear across the rest of the OpenTelemetry repository, with employers listed, which is a different kind of signal from a hobby project with one maintainer.

The project is also an OpenTelemetry one rather than a vendor's. A chart here is packaged from the upstream project rather than a fork, so a bug in the chart is an OpenTelemetry bug and the discussion happens in the OpenTelemetry community, not with a support contract.

The repository has an AGENTS.md and a CLAUDE.md at the top level, and a CONTRIBUTING.md, and the README points contributors at that file for how to contribute.

Where the charts are the wrong tool

Two cases, and both are common.

The first is when you do not want the upstream shape. These charts deploy the OpenTelemetry components the upstream projects build, with the upstream defaults, and they move with upstream releases. A platform team that has standardised on a different configuration management approach, or that wants a Collector configuration it controls end to end, gets more fight from these charts than it does from writing its own manifests. A chart is a packaged opinion, and the opinion here is upstream's.

The second is the demo chart. The OpenTelemetry Demo chart is a demonstration stack, with a demo app, PostgreSQL, Grafana dashboards and fixtures, and the Makefile shows it pulling VCR cassettes and dashboard files from the upstream demo repository. That is a chart for evaluating the system, not for running a production observability pipeline. The same is true of the eBPF instrumentation chart, which is the newest and least settled of the set.

There is also a real operational cost to the signed chart approach, and it is the kind that gets underestimated. Verification requires a gpg agent running on whatever machine performs the install, and in a CI pipeline that means a container or a build agent with gpg configured, not just Helm. Teams that hit this often decide the signature is not worth the plumbing and skip the --verify flag, at which point the signing is decorative.

The chart documentation is where the detail lives. Each chart links to its own directory in the repository, and the top level README deliberately does not duplicate the values reference. Reading the chart directory for the component you want is the step people skip and then regret.

Editorial conclusion

Adopt opentelemetry-helm-charts if you run OpenTelemetry components on Kubernetes and want the upstream charts rather than a hand built deployment, and you are willing to set up a local GPG agent. Do not adopt it if your platform team has standardised on a different packaging route, because these charts track upstream OpenTelemetry releases closely and the app versions move with them. Before you install, import the signing key and export it to the legacy keyring, and verify with the --verify flag, then read the chart directory documentation for the component you actually want rather than the top level README.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. open-telemetry/opentelemetry-helm-charts on GitHub
3. Project website
4. README
5. Releases