# prometheus-community/helm-charts: What the Prometheus Community Repository Actually Ships > The prometheus-community/helm-charts repository is the Helm chart source behind most Kubernetes Prometheus installs, including kube-prometheus-stack. Here is what it contains, how to install from it, and where it stops being the right answer. **prometheus-community/helm-charts** — Prometheus community Helm charts. Prometheus Community Kubernetes Helm Charts This functionality is in beta and is subject to change. - Repository: https://github.com/prometheus-community/helm-charts - Website: https://prometheus-community.github.io/helm-charts/ - Stars: 6,197 · Forks: 5,387 - Language: Mustache - License: Apache-2.0 - Published: 2026-08-04 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/prometheus-community-helm-charts ## What prometheus-community/helm-charts is, and which teams it fits This repository is a collection of Helm charts for Prometheus and its surrounding exporters, maintained under the prometheus-community organisation. The README describes it as the place where the source of all Prometheus community Helm charts lives, and it is published as a chart repository at prometheus-community.github.io/helm-charts. The charts are the deliverable; the repository is not a running service and not a binary you install on a host. The problem it solves is packaging. Running Prometheus on Kubernetes means deploying a server, a set of scrape configurations, alerting rules, and usually an operator that manages those objects as custom resources. Doing that by hand means writing and reconciling a stack of YAML. The charts in this repository turn each piece into a versioned, parameterised unit so that a single release can be installed, upgraded and rolled back as a set. It fits platform teams that already run Helm and want Prometheus installed the same way as the rest of their cluster add-ons. It also fits teams that want a specific component, such as an exporter for Redis or a standalone admission webhook, without pulling in the whole operator stack. The repository layout reflects that: the charts/ directory holds many charts rather than one monolith, and the changelog/ directory tracks releases per chart. Recent releases listed in the repository include kube-prometheus-stack-88.6.1, prometheus-redis-exporter-6.30.0 and prometheus-operator-admission-webhook-0.43.3, all published in late August 2026. ## How the repository is structured and how a chart reaches your cluster The data flow has three stages. First, chart sources live in the charts/ directory of the repository on the main branch, written in the templating language Helm uses. Second, a build process packages and publishes them to a chart repository served from the project's GitHub Pages site, and the same artifacts are also published to ghcr.io as OCI artifacts, which the README points to under the prometheus-community packages. Third, your Helm client resolves a chart name and version from that repository, renders the templates with your values, and applies the result to the cluster through the Kubernetes API. The important consequence is that the repository is a distribution channel, not a controller. Once a chart is rendered and applied, Helm has no ongoing role unless you run it again. Anything that needs to keep reconciling state after installation is handled by the operator deployed by the chart, or by the Prometheus server itself. That distinction matters when comparing this to operators and to GitOps controllers, which sit in the cluster and watch for drift. Chart independence is the other structural fact. Each chart carries its own version, and the release list shows them moving separately: kube-prometheus-stack and prometheus-operator-admission-webhook were both published on 2026-08-28, while prometheus-redis-exporter was published on 2026-08-27. There is no single repository-wide version number to pin against. ## Installing from the repository and running a first search Helm must be installed first; the README defers to Helm's own documentation for that step. Once Helm is set up, add the repository under the name prometheus-community. The README gives this exact command: ```bash helm repo add prometheus-community https://prometheus-community.github.io/helm-charts ``` After adding it, the README states you can run the following to see the charts the repository exposes. Expect a list of chart names and versions, one line per chart, rather than a single package: ```bash helm search repo prometheus-community ``` If you want signature validation, the README requires a local running gpg agent and gives this command to import the signing key: ```bash curl https://prometheus-community.github.io/helm-charts/pubkey.gpg | gpg --import ``` With the key imported, the README states you can pass the --verify flag during helm install to enable chart signature validation. Note that the README does not document a rollback procedure for a failed verification or a failed install; helm rollback exists as a Helm command, but this repository's documentation is silent on it. It also does not describe a canonical first install, so the practical next step is to pick a chart from the search output and read its own values file before applying anything. ## Where this repository is the wrong tool The README is explicit that the functionality is in beta and subject to change, that the code is provided as-is with no warranties, and that beta features are not subject to the support SLA of official GA features. If your organisation needs a contractual support commitment or a guarantee that a values key will not be renamed between minor versions, this is not the source for you. Nothing in the repository overrides that statement. There is a second, quieter failure mode: chart selection. The repository holds a large number of charts, and the names overlap in intent. kube-prometheus-stack bundles the operator and a default set of monitoring components; the prometheus chart is a narrower unit. Installing the wrong one produces a working cluster that is not the one you planned, and the README does not walk through the difference. The search command above is the only guidance it offers. A third case is scope. This repository ships Prometheus components. If your actual need is application dashboards, a log pipeline, or a general-purpose ingress controller, you are in the wrong repository, even though the charts may reference those systems. The repository is not a general Kubernetes add-on catalogue. Finally, signing has an operational precondition that is easy to miss. The README states a local running gpg agent is mandatory for the provenance workflow. In a CI runner or a minimal container without a gpg agent, the verification path described in the README will not work as written. ## How it differs from Bitnami charts and from Terraform The closest comparison in the search data is Bitnami's chart collection, and the difference is scope and stewardship rather than mechanics. Both are Helm chart repositories you add with helm repo add and install from. Bitnami publishes charts across a very broad catalogue of applications; this repository is confined to Prometheus and its ecosystem, maintained by the Prometheus community organisation, with chart sources in a single repository and releases tracked in changelog/. If your stack is Prometheus-shaped, the narrower catalogue means fewer naming collisions with unrelated software and a maintainer group aligned with the upstream project. If you want one repository for everything in your cluster, this is not it. The comparison with Terraform is a category difference. Terraform describes desired infrastructure state and reconciles it against a provider API on every apply, tracking state in a state file. A Helm chart renders templates into Kubernetes manifests and submits them; Helm keeps a release record but does not continuously reconcile the cluster against the chart. Kubernetes controllers do that part, which is why the operator deployed by kube-prometheus-stack exists. Choosing between them is not choosing between two ways to do the same job. The comparison with Argo CD is about who drives the apply. Argo CD watches a Git repository and syncs the cluster toward it. It can consume charts from this repository as its source, which makes the two complementary rather than alternatives. The repository's own contribution guidelines and the .github/ directory describe the project's own automation; the README does not document an Argo CD integration path. ## Maintenance, release cadence and licence terms The repository is not archived, and the most recent push recorded for it is 2026-08-28. The release list shows charts being published on consecutive days in late August 2026, with three separate charts appearing on 2026-08-27 and 2026-08-28. That pattern is consistent with per-chart release automation rather than a single scheduled train, and the presence of renovate.json and a scripts/ directory at the top level supports the reading that dependency updates and packaging are automated. For upgrade cost, the practical unit is the chart, not the repository. Because each chart is versioned independently, an upgrade plan has to name chart versions explicitly. A kube-prometheus-stack bump and a prometheus-redis-exporter bump are separate decisions with separate values surfaces, and the changelog/ directory is where the per-chart history lives. The README does not describe a compatibility matrix between charts, so cross-chart version compatibility is something you establish from your own rendered output. On licensing, the repository is Apache-2.0, and the README links to the LICENSE file in the repository root. Apache-2.0 is a permissive licence that includes an express grant of patent rights and requires preservation of notices. It is not legal advice, and the charts themselves may declare their own licence metadata; the repository-level licence is what the README states. If you redistribute modified charts, read the LICENSE file rather than this summary. ## Contributing, provenance and the beta caveat in practice The repository is open to contributions, with a CONTRIBUTING.md, REVIEW_GUIDELINES.md, CODE_OF_CONDUCT.md, SECURITY.md and MAINTAINERS.md at the top level, plus PROCESSES.md. The README states the source of all Prometheus community Helm charts is on GitHub and points contributors to the contribution guidelines. The presence of AGENTS.md and CLAUDE.md alongside .agents/ indicates the project also documents conventions for automated coding assistants, which is unusual for a chart repository and worth knowing if you plan to open a pull request. The README notes that it syncs from main to gh-pages, which is why it instructs contributors to keep full URL links to repository files rather than relative paths. That is a small detail with a real consequence: a relative link in the README will break on the published site. The beta caveat is not decoration. It means the project has told you the interface can change and that no support SLA applies. Treat the chart values as an interface you do not control, pin chart versions in whatever tool applies them, and read the changelog entry before moving a version. That is the whole of the upgrade discipline the repository's own documentation supports. ## Conclusion Adopt prometheus-community/helm-charts if you run Kubernetes and want the Prometheus operator stack assembled from charts that are signed and versioned per chart, with kube-prometheus-stack as the entry point. Do not adopt it if you need a support SLA or contractual stability: the README states the functionality is in beta, is subject to change, and is provided as-is with no warranties. Before installing, verify three things: that the chart you picked is the one you mean, since the repository holds many charts and kube-prometheus-stack is not the same as the prometheus chart; that your Helm client can run a local gpg agent if you intend to use --verify; and that the values file you plan to apply matches the chart version you resolved, because each chart is released independently and version numbers do not move in lockstep. ## FAQ ### What is prometheus-community/helm-charts used for? It packages Prometheus and its surrounding exporters as Helm charts so they can be installed and upgraded as versioned releases on Kubernetes. The README describes it as the source of all Prometheus community Helm charts, published as a chart repository and also as OCI artifacts in ghcr.io. ### How do I install prometheus-community/helm-charts? Helm must be installed first, then the README gives the command helm repo add prometheus-community https://prometheus-community.github.io/helm-charts. After that you can run helm search repo prometheus-community to list the available charts. ### How do I install prometheus-community/helm-charts in Kubernetes? Add the repository with helm repo add, search it to pick a chart, and install from it. The README does not give a canonical first install, so the next step is to read the chosen chart's values before applying it. ### What are OCI Helm charts and does prometheus-community/helm-charts publish them? OCI artifacts are chart packages distributed through a container registry rather than a classic chart index. The README states that OCI artifacts of all Prometheus Helm charts are available in ghcr.io, with a link to the prometheus-community packages. ### What is prometheus-community/helm-charts in Kubernetes? It is a chart repository for installing Prometheus components into a Kubernetes cluster with Helm. The README notes the functionality is in beta and subject to change, and that the charts are provided as-is with no warranties. ## Sources - [Official documentation](https://prometheus-community.github.io/helm-charts/) - [Official README](https://github.com/prometheus-community/helm-charts#readme) - [Project repository](https://github.com/prometheus-community/helm-charts) - [Release notes](https://github.com/prometheus-community/helm-charts/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/prometheus-community-helm-charts