prometheus-community/prometheus
This page exists so you do not have to guess your way through this Helm chart. It shows the useful ways we know how to run it, the Kubernetes YAML each choice produces, and the evidence behind the current claim.
Start by choosing a base variant. A base variant is a supported Helm configuration such as default, no-CRDs, existing Secret, HA, or server-only.
The page does not claim every values combination for this chart. It shows the supported base variants we have recorded, what problem each one solves, and the chart-specific work that still needs a decision.
Use it to choose the first useful base variant, read the exact objects, catch prerequisites or classic errors, and see what is proven before you install or promote anything.
Pass means backed by evidence. Watch or blocked means the limit is named so you can decide what to do next.
ecosystem: find this chart on Artifact Hub · Helm docs - discovery and tooling live upstream; this page adds the proof.
catalog-supported page for prometheus-community/prometheus@29.8.0.
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 --base server-only-ephemeral --work-dir ./prometheus-community-prometheus-29-8-0-server-only-ephemeral --non-interactive --namespace monitoring
Three ways this page helps you test
The same three things hold for every package in the catalog, Helm charts and OCI packages alike. Why this makes configuration easier to test.
The package fixes and checks almost everything at build time. What you set is small and typed.
Render parity, live install, and delivery, recorded as receipts you can open.
The page names the work and says which delivery path has actually run.
What To Use
server-only-ephemeral base variant: 6 rendered objects · 2 images · 0 lifecycle routes · 5/5 proof lanes passing. Every number is extracted from committed data.
server-only-ephemeralRecommended first base variant
2Supported base variants
render-onlyStart-base status
production-review-readyProduction disposition
Use the public catalog entry, then check the exact base and lane before making a production claim.
| Question | Answer |
|---|
| Catalog level | catalog-supported |
| Chart version | 29.8.0 |
| Installer package OCI | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 |
| OCI publication status | publication receipt recorded |
| Latest upstream seen | 29.9.0 (update candidate) |
| Supported base variants | default;server-only-ephemeral |
| Not yet enabled | ha (curated proof lane - bespoke teaching needed) |
| Namespace | monitoring |
Where This Chart's Settings Come From
Helm values define each base render. ConfigHub changes begin after upload and are recorded against the rendered objects. Secrets, CRDs, hooks, and setup jobs are listed separately because they are install work, not hidden settings. Live cluster state is observed separately and does not silently become the desired configuration.
| Base variant | Helm values | ConfigHub changes | Install work |
|---|
| default | effective-values.yaml | None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant. | No separate work is recorded; read the prerequisite and lifecycle status before assuming none is needed. |
| server-only-ephemeral | effective-values-server-only-ephemeral.yaml | None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant. | No separate work is recorded; read the prerequisite and lifecycle status before assuming none is needed. |
Upgrade rule: if a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion. The values profile shows the Helm side; Unit revision history shows the ConfigHub side.
Read the full values-versus-ConfigHub rule.
What A Base Variant Records
A base variant solves the first Helm problem: which chart inputs should we use, and what Kubernetes objects do they produce? Each base variant records the Helm chart version, values profile, namespace, release name, capability profile, source lock, generated output, and evidence lanes.
The server-only-ephemeral base-variant record joins those Helm facts to the literal objects, remaining target inputs, hooks and CRDs, apply policy, and OCI handoffs. It is the short record to open when you need the whole base rather than only its rendered YAML.
Open the full rendered YAML to read the actual manifest output. Then use the render intent, receipts, and chart-extras section to see the inputs, checks, and CRD/hook/setup decisions around it.
If your values file creates a new useful operating shape, it should become another base variant with its own recorded inputs and checks. If it only changes an already-rendered field after upload, it belongs in a derived ConfigHub variant that can be reviewed and kept through upgrades.
| Key | Where to look first | What it means |
|---|
| Package users pull | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 | The installer package OCI ref for this chart version. After publication, it contains the available bases and package metadata. Public catalog package refs are published in Google Artifact Registry with anonymous read access. No ConfigHub account or Google registry login is needed for the local setup path. |
| Required before apply | None recorded for the recommended base variant.
No separate setup command recorded. | External resources the recommended base variant expects, such as an existing Secret, namespace, CRD, or target fact. |
| Kubernetes objects | full rendered YAML | The full YAML captured from this base variant. It is the output of the render. |
| Render record | server-only-ephemeral render intent | The Helm inputs and evidence links that explain how the output was produced. |
| Base variant record | server-only-ephemeral base-variant record | The source-neutral record that joins the Helm record, literal objects, remaining inputs, routes, policy, and OCI status. |
| Hooks, CRDs, and setup work | this page's chart-extras section | The route decisions for non-plain-YAML work: hooks, CRDs, generated Secrets, setup jobs, target facts, or blockers. |
Choose base variant
Pick the supported Helm configuration for this chart: default, no-CRDs, existing Secret, HA, server-only, or another listed option.
Record inputs
Keep the values profile, namespace, release name, source lock, server-only-ephemeral render intent, full YAML output, package base, proof lanes, and route context together.
Handle chart extras
CRDs, hooks, setup jobs, external Secrets, target facts, and webhook certificates are recorded as chart-specific choices. Some are included in a base variant, some need a setup step, and some are blocked until there is a safe path.
How render intents work · All generated render intents · All base variant records
How To Try This Chart
Start with server-only-ephemeral unless a card below explains that another base variant is a better first path. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.
Package image
oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0
publication receipt recorded
Public catalog package refs are published in Google Artifact Registry with anonymous read access. No ConfigHub account or Google registry login is needed for the local setup path.
Recommended first command
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 --base server-only-ephemeral --work-dir ./prometheus-community-prometheus-29-8-0-server-only-ephemeral --non-interactive --namespace monitoring
Or run the whole sequence as one script, prerequisites included: try.sh (render and apply, no account) · confighub.sh (render and upload to your ConfigHub Space).
This preset is also shown in the live helm-catalog demo org. Read the demo README to see why that Space exists, what problem it demonstrates, and what to inspect first.
You should see something like this
New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.
What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.
cub installer setup ...
rendered manifests written under <work-dir>
use the chart option cards below to check pass, watch, blocked, and prerequisites
Current status: Available in the catalog · Reason: Server side promotion mechanics passed; But changeset bound promote failed and required the no changeset fallback
Prometheus Teaching Path
Use Prometheus when you want a familiar public chart without starting with Bitnami image questions. The server-only-ephemeral base is the small teaching path; the default base remains in the catalog for broader chart coverage.
Normal Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install prometheus prometheus-community/prometheus --version 29.8.0 --namespace monitoring --create-namespace
You should see Helm create a Prometheus release and Kubernetes objects in the namespace.
cub installer
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 --base server-only-ephemeral --work-dir ./prometheus-server-only --non-interactive --namespace monitoring
You should see rendered manifests in the work directory, ready to inspect before delivery.
ConfigHub
cub installer upload --work-dir ./prometheus-server-only --space helm-prometheus-server-only
You should see Prometheus Units in ConfigHub. Derived variants can start from that uploaded base.
Open Get Started · Expected results and clusters
Base Variants And Options
Each card is one available way to use this chart in the catalog. Some cards are runnable base variants. Others are candidate paths, derived variants, or review notes that explain what still has to be prepared.
Check labels: R = render parity, C = ConfigHub proof, L = local cluster, Y = lifecycle actions, G = GitOps/OCI, P = live Helm-vs-ConfigHub parity, K = two-cluster kind parity, V = variant promotion.
7 matrix rows for prometheus-community/prometheus@29.8.0 · open the full matrix
Upstream chart source
- Status
- Available in the catalog
- How to run
- This is the upstream chart source. Choose a base card below before running the installer.
- Evidence
- Pinned chart source and dependency lock
- Hooks/actions
- No separate hook or action for this row.
- Who runs actions?
- No separate action runner for this row.
- Next
- Choose or create an F2 base before rendering or deploying
- Reason
- Source rows are upstream chart inputs; Not server side promotion evidence
Rn/aCn/aLn/aYn/aGn/aPn/aKn/aVn/a
catalog · source repo
F2a honest default base
- Status
- Available in the catalog
- Helm values
- effective-values.yaml
- ConfigHub changes
- None in this catalog base. After upload, read Unit revision history or the derived variant.
- How to run
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 --base default --work-dir ./prometheus-community-prometheus-29-8-0-default --non-interactive --namespace monitoring- Scripts
- try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
- Evidence
- Live helm vs confighub parity
- Hooks/actions
- No separate hook or action for this row.
- Who runs actions?
- No separate action runner for this row.
- Lifecycle record
- The current review found no separate hook or setup route for this base. Open the full record.
- Prerequisites
- This base has not yet been reviewed for required Secrets, CRDs, namespaces, values, storage services, external APIs, or target topology. Record what it needs, or record that nothing extra is required.
- Next
- Choose the target ready base; Then record explicit security acceptance or create a hardened base before claiming a target run path
- Reason
- Server side promotion receipt passed
RyesCyesLyesYn/aGyesPyesKtodoVyes
Demo README · catalog · variant · full YAML · render intent · base record · package base · receipt · source repo
F2b
server-only-ephemeral
Base
Runnable base variant
- Status
- Available in the catalog
- Helm values
- effective-values-server-only-ephemeral.yaml
- ConfigHub changes
- None in this catalog base. After upload, read Unit revision history or the derived variant.
- How to run
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 --base server-only-ephemeral --work-dir ./prometheus-community-prometheus-29-8-0-server-only-ephemeral --non-interactive --namespace monitoring- Scripts
- try.sh renders, settles the prerequisites in order, and applies with kubectl; confighub.sh renders and uploads to your ConfigHub Space.
- Evidence
- Live helm vs confighub parity
- Hooks/actions
- No separate hook or action for this row.
- Who runs actions?
- No separate action runner for this row.
- Lifecycle record
- The current review found no separate hook or setup route for this base. Open the full record.
- Prerequisites
- This base has not yet been reviewed for required Secrets, CRDs, namespaces, values, storage services, external APIs, or target topology. Record what it needs, or record that nothing extra is required.
- Next
- Choose the target ready base; Then record explicit security acceptance or create a hardened base before claiming a target run path
- Reason
- Server side promotion mechanics passed; But changeset bound promote failed and required the no changeset fallback
RyesCyesLyesYn/aGyesPyesKtodoVwatch
Demo README · catalog · variant · full YAML · render intent · base record · package base · receipt · source repo
Derived ConfigHub variant
- Status
- Needs more work before this is a ready path
- How to run
- A ConfigHub variant based on default for Prometheus-prod-us-east. Upload the base first, then create or promote this variant in ConfigHub.
- Evidence
- ConfigHub variant clone evidence
- Hooks/actions
- No separate hook or action for this row.
- Who runs actions?
- No separate action runner for this row.
- Next
- Create this as a ConfigHub variant after the base has been uploaded.
- Reason
- No target was attached; This is a ConfigHub intended state proof; Not a live cluster deployment.
Rn/aCyesLn/aYn/aGtodoPn/aKn/aVn/a
catalog · variant · full YAML · package base · receipt · source repo
F4a
staging-eu-west
Variant
Derived ConfigHub variant
- Status
- Needs more work before this is a ready path
- How to run
- A ConfigHub variant based on default for Prometheus-staging-eu-west. Upload the base first, then create or promote this variant in ConfigHub.
- Evidence
- ConfigHub variant clone evidence
- Hooks/actions
- No separate hook or action for this row.
- Who runs actions?
- No separate action runner for this row.
- Next
- Create this as a ConfigHub variant after the base has been uploaded.
- Reason
- No target was attached; This is a ConfigHub intended state proof; Not a live cluster deployment.
Rn/aCyesLn/aYn/aGtodoPn/aKn/aVn/a
catalog · variant · full YAML · package base · receipt · source repo
Derived ConfigHub variant
- Status
- Available in the catalog
- How to run
- A ConfigHub variant based on server-only-ephemeral for Prometheus-prod-us-east. Upload the base first, then create or promote this variant in ConfigHub.
- Evidence
- This is a target-bound derived variant.
- Hooks/actions
- No separate hook or action for this row.
- Who runs actions?
- No separate action runner for this row.
- Next
- Refresh the receipt when the source base or target changes.
- Reason
- Derived ConfigHub variant creation is not the base variant promotion lane
Rn/aCyesLn/aYn/aGyesPn/aKn/aVn/a
catalog · variant · full YAML · package base · receipt · source repo
F4b
staging-eu-west
Variant
Derived ConfigHub variant
- Status
- Available in the catalog
- How to run
- A ConfigHub variant based on server-only-ephemeral for Prometheus-staging-eu-west. Upload the base first, then create or promote this variant in ConfigHub.
- Evidence
- This is a target-bound derived variant.
- Hooks/actions
- No separate hook or action for this row.
- Who runs actions?
- No separate action runner for this row.
- Next
- Refresh the receipt when the source base or target changes.
- Reason
- Derived ConfigHub variant creation is not the base variant promotion lane
Rn/aCyesLn/aYn/aGyesPn/aKn/aVn/a
catalog · variant · full YAML · package base · receipt · source repo
Images This Chart Pulls
Every reference below comes from the reviewed rendered output. What you see is what the cluster pulls. These references are data: you can change a registry or pin a digest with a recorded edit, and prove the change landed in every environment.
| Base variant | Images |
|---|
| default | quay.io/prometheus-operator/prometheus-config-reloader:v0.91.0
quay.io/prometheus/alertmanager:v0.32.1
quay.io/prometheus/node-exporter:v1.11.1
quay.io/prometheus/prometheus:v3.11.3
quay.io/prometheus/pushgateway:v1.11.2
registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.19.0 |
| server-only-ephemeral | quay.io/prometheus-operator/prometheus-config-reloader:v0.91.0
quay.io/prometheus/prometheus:v3.11.3 |
First-Run Caveats
Some chart paths need a small preparation step before the cub path feels as smooth as Helm. We show those steps here so the first run does not surprise you.
| Caveat | What to do |
|---|
| Universal caveats | Use declared inputs or bases instead of Helm --set. For direct delivery, define pruning and field-conflict behavior. Use Argo CD or Flux when that controller path is recorded for the selected preset. |
| Shared placeholder password | No shared placeholder password caveat recorded for this chart. |
| CRD first-ordering | No CRD first-ordering caveat recorded for this chart. |
Open the all-chart adoption caveats · Helm to cub migration · cub deployment path
Operator Playbooks And Fact Sheet
This is the quick route for a human or agent: which operating playbook applies, what the current user-facing answer is, and what the next proof or product action would add.
| Fact | Current chart-level route |
|---|
| User status | ready-to-try |
| Can I use it? | yes-public-catalog |
| First base | server-only-ephemeral |
| Installer package OCI | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-prometheus:29.8.0 |
| Current proof | catalog-supported-with-live-evidence (render parity 2/2, local live 2/2, live parity 2/2) |
| Coverage | covered |
| User must provide | a StorageClass / storage decision; target facts at variant time; mandatory chart inputs |
| ConfigHub/installer absorbs | exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; extension slots routed to reviewed bases; cluster lookups lifted into declared target facts |
| Next action | choose the supported production base, then record explicit security acceptance or create a hardened base before claiming production support |
The source data lives in chart skills and chart evidence router.
Proof Lanes
Each lane proves a different outcome. Missing or non-pass rows are backlog or target-fit evidence; they do not change the render-parity result.
How much is proven, and what more testing would add: Fully proven: Render parity, ConfigHub proof, Local live, GitOps/OCI live, Live Helm-vs-ConfigHub. Not yet tested: Two-cluster kind - a fresh cluster run would prove these.
| Lane | Status across bases |
|---|
| Render parity | pass: 2/2 |
| ConfigHub proof | pass: 2/2 |
| Local live | pass: 2/2 |
| GitOps/OCI live | pass: 2/2 |
| Live Helm-vs-ConfigHub | pass: 2/2 |
| Two-cluster kind | missing: 2/2 |
| Base | Readiness | Render | ConfigHub | Local live | GitOps/OCI | Live parity | Two-cluster kind |
|---|
| server-only-ephemeral | render-only | pass | pass | pass | pass | pass | missing |
| default | render-only | pass | pass | pass | pass | pass | missing |
What We Tested On A Cluster
This is the result of a real run for one base variant on one recorded target setup. It does not silently extend the result to other bases or clusters.
| Question | Recorded answer |
|---|
| Base variant | default |
| Target used | cub-managed kind proof cluster with ConfigHub OCI source |
| Observed result | pass |
| What passed | regular Helm live leg reached the expected runtime state
ConfigHub direct-apply leg reached the expected runtime state
ConfigHub OCI/Argo leg reached the expected workload runtime state
ConfigHub OCI/Argo Application reached Synced/Healthy
Helm-vs-ConfigHub semantic parity passed for the OCI/Argo leg
Prometheus server Deployment, Alertmanager StatefulSet, node-exporter DaemonSet, kube-state-metrics Deployment, and pushgateway Deployment became ready |
| What the result means | The desired OCI artifact materializes Kubernetes StatefulSet defaults that Argo otherwise reports as drift after server-side apply. |
| What this does not prove | This review does not prove production Prometheus storage, retention, HA, backup, or alert routing policy.
This review does not generalize to every StatefulSet chart without a matching live receipt. |
| Full review and receipt | Open the runtime review · open the live receipt |
Quirks And Inputs
exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; extension slots routed to reviewed bases; cluster lookups lifted into declared target facts
| Field | Value |
|---|
| Known quirks | generated-secrets;extension-slots;required-values;generated-facts;tpl;capabilities;rbac;storage |
| User must provide | a StorageClass / storage decision; target facts at variant time; mandatory chart inputs |
| ConfigHub absorbs | exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; extension slots routed to reviewed bases; cluster lookups lifted into declared target facts |
| Extension slots | raw/extra manifests; monitoring config |
| Extension route | keep empty in supported bases, or make a reviewed installer base when populated |
Hooks, CRDs, And Setup Work
Some Helm charts need work before, during, or after apply: CRDs, hooks, setup jobs, webhook certificates, migrations, generated Secrets, or checks. For each chart, the catalog should make the choice clear: include it in the base variant, split it into a separate base variant, run a setup step, use a GitOps action where evidence exists, require an existing target resource, or block it when there is no safe default.
If no route is shown, that does not prove the upstream chart has no hooks. It means the public catalog has no chart-specific action to show yet; check the matrix or send a problem chart if hook behavior should be modeled. Direct apply, Argo CD, Flux, and upgrade implementations are tracked separately. One passing implementation does not prove the others.
Production Boundary
A green render or local live result is not a production support claim. Production support is target-scoped and uses the support-decision artifact when present.
| Field | Value |
|---|
| Production disposition | production-review-ready |
| Target-scoped support decision | supported |
| Supported base | server-only-ephemeral |
| Target scope | vanilla kind (historical receipt); namespace=monitoring; delivery=confighub-oci; controller=argo |
| Accepted dispositions | cluster RBAC review; extension slot provenance and scan policy; scan/gate warning disposition |
| Open policy dispositions | none recorded for this policy checklist |
| Next action | Keep the target-scoped evidence fresh before using this supported scope as a production-support example; create separate default-stack, persistent-storage, remote-write, scrape-customization, ingress, node-exporter, resource-hardened, or digest-pinned bases for real customer monitoring workloads. |