The Catalog holds six versions of the Helm chart prometheus-community/kube-prometheus-stack, with 16 bases across them. The newest is 88.6.3.
The Catalog files this chart under Monitoring and logs. Its listings do not yet describe what it does, so read the objects before you rely on the name.
The Catalog rendered all 16 bases and retains the exact objects of each. The listings record an upload as a variant for 4 bases. They record no deployment for any base. A promoted change is partly recorded for 4 bases.
Use this entry in ConfigHub in five steps, from fetching its exact objects to promoting a change.
Pick a version · See what changes · Back to the Catalog
Guides. Make a stack from Catalog entries shows how to combine this chart with others and check them together.
What it is. prometheus-community/kube-prometheus-stack 88.6.3, as 125 Kubernetes objects in its default preset.
Install it. Use its installer package with cub installer. The five steps below give the commands.
Needs first. The package applies the locked CRDs before the chart objects that use them. The run removes both completed Jobs and their temporary RBAC objects. The plan below lists 6 more.
How it works. How the model works, and Helm in the Catalog.
Versions are listed newest first. Each row is one base, and every cell is read from that base's listing. A base marked watch has a checked result with a limit to review.
3 bases. The installer package is published and signed. Open the page for 88.6.3.
| Base | Objects | Flattening verdict | Published as OCI | Flag | Open |
|---|---|---|---|---|---|
| default default | 125 | unsafe-to-flatten | Not published | None | exact objects · listing |
| no-crds | 115 | unsafe-to-flatten | Not published | None | exact objects · listing |
| existing-secret | 124 | unsafe-to-flatten | Not published | None | exact objects · listing |
3 bases. The installer package is published and signed. Open the page for 87.19.2.
| Base | Objects | Flattening verdict | Published as OCI | Flag | Open |
|---|---|---|---|---|---|
| default default | 125 | unsafe-to-flatten | Not published | None | exact objects · listing |
| no-crds | 115 | unsafe-to-flatten | Not published | None | exact objects · listing |
| existing-secret | 124 | unsafe-to-flatten | Not published | None | exact objects · listing |
3 bases. The installer package is published and signed. Open the page for 87.15.1.
| Base | Objects | Flattening verdict | Published as OCI | Flag | Open |
|---|---|---|---|---|---|
| default default | 125 | unsafe-to-flatten | Not published | None | exact objects · listing |
| no-crds | 115 | unsafe-to-flatten | Not published | None | exact objects · listing |
| existing-secret | 124 | unsafe-to-flatten | Not published | None | exact objects · listing |
2 bases. The installer package is published and signed. Open the page for 86.1.0.
| Base | Objects | Flattening verdict | Published as OCI | Flag | Open |
|---|---|---|---|---|---|
| default default | 124 | unsafe-to-flatten | Not published | None | exact objects · listing |
| no-crds | 114 | unsafe-to-flatten | Not published | None | exact objects · listing |
2 bases. The installer package is published and signed. Open the page for 85.3.3.
| Base | Objects | Flattening verdict | Published as OCI | Flag | Open |
|---|---|---|---|---|---|
| default default | 124 | unsafe-to-flatten | Not published | None | exact objects · listing |
| no-crds | 114 | unsafe-to-flatten | Not published | None | exact objects · listing |
3 bases. The installer package is published and signed. Open the page for 84.4.0.
| Base | Objects | Flattening verdict | Published as OCI | Flag | Open |
|---|---|---|---|---|---|
| default default | 126 | flatten-with-routes | Not published | watch | exact objects · listing |
| aicr-eks-training-v0-20-0 | 116 | flatten-with-routes | Not published | watch | exact objects · listing |
| aicr-eks-training-v1-0-0 | 116 | flatten-with-routes | Not published | watch | exact objects · listing |
Choose two versions or two bases, then press Compare. The page fetches the two retained files and checks each file's SHA-256 against the digest its listing records. It then computes the diff on demand, in your browser, with the code that cub config diff runs. Nothing is precomputed or stored.
These commands fetch the same two files and compare them on your machine, with no account. They follow the pair you choose above. cub plugin install confighub/cub-workshop@v0.6.61 adds cub config diff.
# fetch the first retained file
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-19-2-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.19.2/revisions/default/r001/rendered/release-objects.yaml
# fetch the second retained file
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-88-6-3-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/88.6.3/revisions/default/r001/rendered/release-objects.yaml
# check the bytes against the two listings
$ shasum -a 256 prometheus-community-kube-prometheus-stack-87-19-2-default.yaml prometheus-community-kube-prometheus-stack-88-6-3-default.yaml
f93812ce23b92c73c0bcc223d5c4efd125e80430b846dc41aa874eee09f67d99 prometheus-community-kube-prometheus-stack-87-19-2-default.yaml
7b1bb6bd944ccfff3fa9e42b82a1fe442ddffefccf28f08f670b841c12906f4d prometheus-community-kube-prometheus-stack-88-6-3-default.yaml
# count what changes
$ cub config diff prometheus-community-kube-prometheus-stack-87-19-2-default.yaml prometheus-community-kube-prometheus-stack-88-6-3-default.yaml --summary
# list every changed field
$ cub config diff prometheus-community-kube-prometheus-stack-87-19-2-default.yaml prometheus-community-kube-prometheus-stack-88-6-3-default.yamlThese lines are the only diff content this page stores. Each one was computed when the site was generated, by the same code, on the default base of both versions.
Every Catalog entry page carries these five steps in this order. Each step says what the Catalog has run for this entry, and a step with a missing precondition gives no command.
Steps 1 and 2 need no account. Install the cub CLI before any cub command. Step 2 uses cub config diff, which cub plugin install confighub/cub-workshop@v0.6.61 adds. A live walk on 2026-10-08 ran steps 3 to 5 for bitnami-nginx-24-0-2-http-clusterip and nvidia-gpu-operator-v26-3-3-default. These commands carry the changes that walk needed. It is a dated log and no receipt, so no state on this page rests on it. These are the steps for 88.6.3, the newest version, on its default base.
Fixed when this entry was built. These went into the build, so the objects already carry them. To change one, build the entry again from its source.
chart is prometheus-community/kube-prometheus-stackversion is 88.6.3base is defaultvaluesProfile is recipes/prometheus-community/kube-prometheus-stack/88.6.3/effective-values.yamlnamespace is monitoringreleaseName is kube-prometheus-stackcapabilityProfile is {"apiVersions":[],"kubeVersion":"1.30.0"}Yours to supply or check. The destination must have these before the objects are applied. The words in italics say what the Catalog knows about each.
These are the steps that plain objects cannot carry. ConfigHub stores them and does not carry them out. The words in italics say what the Catalog knows about each.
The Catalog rendered this entry and retains its 125 objects in one file.
An upload can create more Units than the objects counted here. The installer renders a Namespace, and the upload adds an installer-record Unit.
Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.
# fetch the retained objects for this entry
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-88-6-3-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/88.6.3/revisions/default/r001/rendered/release-objects.yaml
# check the bytes against the listing
$ shasum -a 256 prometheus-community-kube-prometheus-stack-88-6-3-default.yaml
7b1bb6bd944ccfff3fa9e42b82a1fe442ddffefccf28f08f670b841c12906f4d prometheus-community-kube-prometheus-stack-88-6-3-default.yaml
# render this base from the signed package; step 3 uploads this directory
$ cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:88.6.3@sha256:ee4622c4d2a34dbe1a85a6fbaa56cc47a9440dcdf88047b5776dd6689bfff44a --base default --work-dir ./prometheus-community-kube-prometheus-stack-88-6-3-default --non-interactive --namespace monitoringThe listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 2 other bases in the Catalog, existing-secret and no-crds. The Catalog holds 5 other versions, 84.4.0, 85.3.3, 86.1.0, 87.15.1 and 87.19.2.
# fetch the existing-secret base of the same version
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-88-6-3-existing-secret.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/88.6.3/revisions/existing-secret/r001/rendered/release-objects.yaml
# list what differs between the two bases
$ cub config diff prometheus-community-kube-prometheus-stack-88-6-3-default.yaml prometheus-community-kube-prometheus-stack-88-6-3-existing-secret.yaml --summary
# fetch the default base at version 87.19.2
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-19-2-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.19.2/revisions/default/r001/rendered/release-objects.yaml
# list what changed from 87.19.2 to 88.6.3
$ cub config diff prometheus-community-kube-prometheus-stack-87-19-2-default.yaml prometheus-community-kube-prometheus-stack-88-6-3-default.yaml --summaryThe Catalog has not uploaded this entry. The commands use its signed installer package. Read the log of the live walk on 2026-10-08.
Replace each value in angle brackets with a name of your own. The entry id may already exist as a Space in your organization, and the package name as a Component.
In the live walk, a Space named for the nginx entry's id and a Component named bitnami-nginx already existed, so the walk chose its own names. The --component flag sets the Component label the upload writes on the Space, which is the package name when you omit it.
The cub installer plugin reads your organization from CUB_CONTEXT and ignores --context. If you use a context other than your default, export CUB_CONTEXT first, or the plugin works in your default organization.
# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login
# upload step 1's directory as a Space of Units, under names you choose
$ cub installer upload --work-dir ./prometheus-community-kube-prometheus-stack-88-6-3-default --space <your-space> --component <your-component>
# list the Units the upload created
$ cub unit list --space <your-space>No delivery run is recorded for this entry. Argo CD has not run, Flux has not run, and kubectl has not run. The commands name the Target workshop/target, which cub cluster up --name workshop creates on a local kind cluster with Argo CD. Use your own Target for a real destination. The listing records one input that the destination must supply, so read it before you deploy. The base carries 10 CRDs it needs, so the destination does not supply them. The coverage lanes record a GitOps OCI run for this base. They are separate from the delivery record this step reads. Read the log of the live walk on 2026-10-08.
Use the Space name you chose in step 3. The delete command is needed because the cloned installer-record Unit carries the Target and Argo CD v3.5.4 cannot read it, a defect seen on cub v0.8.7 and server v0.8.9.
Without that line the walk deployed nothing and Argo CD showed Unknown, while every cub command exited 0. The walk ran the four commands in this order and did not try them without the first publish.
ConfigHub shows nothing when Argo CD fails to read a Release. Run kubectl -n argocd get applications.argoproj.io and read the Sync column, because Healthy alone is not a pass. Argo CD took between 18 seconds and about 5 minutes to read a Release on a cluster made without argobot.
The walk made its cluster with cub cluster up --no-argobot. That command creates two Spaces, a Worker, a Target and a Trigger, opens ports 30010 to 30019 on the machine, and installs Argo CD from an unpinned upstream manifest.
Removing the ConfigHub side does not remove the workload. In the walk, deleting the Application Unit and the Spaces left the Application and its pods running, because the root Application does not prune.
# clone the base onto a Target as a dev variant
$ cub variant create dev <your-space> --target workshop/target --space-pattern "template:<your-space>-dev"
# publish the Release that the cluster's Argo CD pulls
$ cub release publish <your-space>-dev
# delete the installer record, which Argo CD cannot read
$ cub unit delete --space <your-space>-dev installer-record
# publish again without it
$ cub release publish <your-space>-devNo promotion is recorded for this entry. Promotion carries a change in the base to the dev variant. The base changes when you edit a Unit or upload a newer version into the same Space. Read the log of the live walk on 2026-10-08.
The promotion changes the dev Space and publishes nothing. It also adds the installer-record Unit back with the Target. The change reaches the cluster only after the delete and the publish.
The preview lists the whole installer record as added. In the walk, the preview of a one-label change to gpu-operator ran to 405 lines, and about 400 of them were that record.
# preview what the dev variant would take from the base
$ cub variant promote <your-space>-dev --dry-run -o mutations
# promote once you have read the preview
$ cub variant promote <your-space>-dev --change-desc "Pull the reviewed base forward"
# delete the installer record that the promotion adds back
$ cub unit delete --space <your-space>-dev installer-record
# publish the Release that carries the change
$ cub release publish <your-space>-devEvery other base carries the same five steps, with its own states and commands, on the page of its version.
One file holds everything on this page in a form a program can read.