What it is. prometheus-community/kube-prometheus-stack 87.19.2, as 125 Kubernetes objects in its default preset. The Catalog holds 4 presets of this version.
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.
What this page gives you
This is a human-readable detail page for one retained package version. It keeps the package, base names, exact OCI identity, and publication receipt reachable without pretending this retained-only version has the richer readiness evidence attached to the bold version in the component row.
Where its settings and observations live
Each packaged configuration records Helm-derived files and installer metadata. Later ConfigHub changes belong in governed variants. Target prerequisites and live observations remain separate facts; this publication receipt does not turn them into passes.
Four Separate Questions
Inspecting a source, producing objects, checking a destination, and checking a live result are different jobs. A Catalog match is useful for comparison but is not required. A missing destination or deployment is shown as not run or blocked, not as a failed configuration.
| Question | Current answer | What it needs | Status |
|---|---|---|---|
| What do I have? | Inspect the helm source, choices, locks, and any existing output before selecting a destination. | Destination access: no Selected configuration deployed: no | Available to inspect evidence recorded |
| What will it produce? | Run the recorded Helm render step to produce the exact Kubernetes objects for this configuration. | Destination access: no Selected configuration deployed: no | Checked: passed evidence recorded |
| Can this destination accept it? | No destination answer is available yet because target facts or lifecycle handling are incomplete. | Destination access: yes Selected configuration deployed: no | Answer pending evidence pending |
| Did it work? | No post-deployment result is recorded for this exact configuration. Publication, upload, or rendering is not proof that it ran correctly. | Destination access: yes Selected configuration deployed: yes | Not run no run recorded |
Open the complete assessment, source, lifecycle, and evidence record.
Try This Chart
Inspect the exact package first, then choose one of the packaged configurations. The version remains readable in the reference, and the manifest digest prevents the registry from returning different package bytes. The setup command renders files locally; it does not apply them to Kubernetes.
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.
cub installer inspect oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987 --json
cub installer setup --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987 --base default --work-dir ./prometheus-community-kube-prometheus-stack-87-19-2-default --non-interactive
Run shared local configuration checks after the package has written its Kubernetes YAML:
cub plugin install confighub/homebrew-tap@cub-scan-v0.7.3 --name scan
cub check --format json --output cub-check.json <work-dir>/out/manifests
The check is advisory and does not apply anything.
Version tag: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:87.19.2
Exact package: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987
The manifest digest comes from the committed publication receipt. cub installer refuses the pull if that exact manifest is not available.
Verify the package publisher
Run this command with cosign. It checks the expected publisher, the exact manifest digest, and the package annotations.
cosign verify --certificate-identity helm-expt-package-signer@nth-fort-499605-q5.iam.gserviceaccount.com --certificate-oidc-issuer https://accounts.google.com --annotations confighub.com/package-path=packages/prometheus-community/kube-prometheus-stack/87.19.2 --annotations confighub.com/package-sha256=677058d72313c3c124a4eea80a280d5a1f63145d09079f6f3a8565c9d9c33ca4 europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987
A valid signature identifies who signed these package bytes. It does not show that the configuration is suitable for your cluster; use this page's checks and setup instructions for that decision.
Signature receipt · Sigstore bundle · How signature verification works
Use this entry in ConfigHub
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. This page covers 4 entries, so open the one you want. 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.
Helm chart, base default, version 87.19.2
What is fixed, and what you supply
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.
chartisprometheus-community/kube-prometheus-stackversionis87.19.2baseisdefaultvaluesProfileisrecipes/prometheus-community/kube-prometheus-stack/87.19.2/effective-values.yamlnamespaceismonitoringreleaseNameiskube-prometheus-stackcapabilityProfileis{"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.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator admission webhook TLS material created by the packaged chart-specific setup Job. package://prerequisites/kube-prometheus-stack-lifecycle/prepare.sh Declared. Not checked on any destination.
This entry's plan, and how to test it
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.
- Before you deliver. The package applies the locked CRDs before the chart objects that use them. Who: cub installer package script. Recorded as routed.
- After you deliver. The run removes both completed Jobs and their temporary RBAC objects. Who: delivery workflow. Recorded as routed.
- After you deliver. The package runs the chart's webhook patch Job after the webhook objects exist. Who: delivery workflow. Recorded as routed.
- Before you deliver. The package runs the chart's certificate creation Job before applying the admission webhooks. Who: delivery workflow. Recorded as routed.
- Around an upgrade. The direct package route upgraded the default preset from 85.3.3 to 86.1.0, established the updated CRDs, retained the admission Secret, reran the webhook step, checked six workloads, and and more. The listing gives the rest. Who: delivery workflow. Recorded as routed.
- Before you deliver. The direct runner applies CRDs, creates the certificate, applies the workload, and patches the webhooks in that order. Who: delivery workflow. Recorded as routed.
- Before you deliver. The certificate Job creates the required admission Secret with ca, cert, and key. Who: operator. Recorded as routed.
- After you deliver. The run checks three CA bundles, the operator endpoint, a server dry-run, and six workloads. Who: delivery workflow. Recorded as routed.
1. Get the exact objects Run for this entry
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.
# fetch the retained objects for this entry
$ 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
# check the bytes against the listing
$ shasum -a 256 prometheus-community-kube-prometheus-stack-87-19-2-default.yaml
f93812ce23b92c73c0bcc223d5c4efd125e80430b846dc41aa874eee09f67d99 prometheus-community-kube-prometheus-stack-87-19-2-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:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987 --base default --work-dir ./prometheus-community-kube-prometheus-stack-87-19-2-default --non-interactive --namespace monitoring
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 3 other bases in the Catalog, existing-secret, minimal and no-crds. The Catalog holds 5 other versions, 84.4.0, 85.3.3, 86.1.0, 87.15.1 and 88.6.3.
# fetch the existing-secret base of the same version
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.19.2/revisions/existing-secret/r001/rendered/release-objects.yaml
# list what differs between the two bases
$ cub config diff prometheus-community-kube-prometheus-stack-87-19-2-default.yaml prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.yaml --summary
# fetch the default base at version 87.15.1
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-15-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.15.1/revisions/default/r001/rendered/release-objects.yaml
# list what changed from 87.15.1 to 87.19.2
$ cub config diff prometheus-community-kube-prometheus-stack-87-15-1-default.yaml prometheus-community-kube-prometheus-stack-87-19-2-default.yaml --summary
3. Upload it as a variant Not run for this entry
The 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-87-19-2-default --space <your-space> --component <your-component>
# list the Units the upload created
$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
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>-dev
5. Promote a change Not run for this entry
No 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>-dev
Helm chart, base existing-secret, version 87.19.2
What is fixed, and what you supply
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.
chartisprometheus-community/kube-prometheus-stackversionis87.19.2baseisexisting-secretvaluesProfileisrecipes/prometheus-community/kube-prometheus-stack/87.19.2/effective-values-existing-secret.yamlnamespaceismonitoringreleaseNameiskube-prometheus-stackcapabilityProfileis{"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.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD included in this preset and applied before dependent objects. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Grafana admin credentials managed by the target secret backend. ExternalSecret monitoring/grafana-admin-credentials or an equivalent target-owned Secret Declared. Not checked on any destination.
- Prometheus Operator admission webhook TLS material created by the packaged chart-specific setup Job. package://prerequisites/kube-prometheus-stack-lifecycle/prepare.sh Declared. Not checked on any destination.
This entry's plan, and how to test it
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.
- After you deliver. Your cluster - at uninstall, automatically Who: Kubernetes. Seen in a recorded run.
- After you deliver. Your delivery - a post-apply check (receipted) Who: delivery workflow. Seen in a recorded run.
- Before you deliver. kubectl apply -f <preflight-job>; kubectl wait --for=condition=complete job/<name> Who: delivery workflow. Seen in a recorded run.
- Around an upgrade. kubectl apply -f <action-job>; kubectl wait --for=condition=complete job/<name> Who: delivery workflow. Seen in a recorded run.
- Before you deliver. Your applier - must apply CRDs before dependent objects Who: whatever applies the objects. Seen in a recorded run.
- Before you deliver. # create the required target facts (Secret/StorageClass/etc.) before apply Who: operator. Seen in a recorded run.
- After you deliver. kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations Who: delivery workflow. Seen in a recorded run.
1. Get the exact objects Run for this entry
The Catalog rendered this entry and retains its 124 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.
# fetch the retained objects for this entry
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.19.2/revisions/existing-secret/r001/rendered/release-objects.yaml
# check the bytes against the listing
$ shasum -a 256 prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.yaml
c0a62fce6407f18a6cbadb712a2b2570f51522f55bddc9ecaffcf30c5192ed2b prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.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:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987 --base existing-secret --work-dir ./prometheus-community-kube-prometheus-stack-87-19-2-existing-secret --non-interactive --namespace monitoring
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 3 other bases in the Catalog, default, minimal and no-crds. The Catalog holds 5 other versions, 84.4.0, 85.3.3, 86.1.0, 87.15.1 and 88.6.3.
# fetch the default base of the same version
$ 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 differs between the two bases
$ cub config diff prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.yaml prometheus-community-kube-prometheus-stack-87-19-2-default.yaml --summary
# fetch the existing-secret base at version 87.15.1
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-15-1-existing-secret.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.15.1/revisions/existing-secret/r001/rendered/release-objects.yaml
# list what changed from 87.15.1 to 87.19.2
$ cub config diff prometheus-community-kube-prometheus-stack-87-15-1-existing-secret.yaml prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.yaml --summary
3. Upload it as a variant Not run for this entry
The 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-87-19-2-existing-secret --space <your-space> --component <your-component>
# list the Units the upload created
$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
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 2 inputs that the destination must supply, so read them before you deploy. The base carries 10 CRDs it needs, so the destination does not supply them. 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>-dev
5. Promote a change Not run for this entry
No 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>-dev
Helm chart, base minimal, version 87.19.2
What is fixed, and what you supply
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.
chartisprometheus-community/kube-prometheus-stackversionis87.19.2baseisminimalvaluesProfileisruns/prometheus-operator-minimal-candidate/recipes/prometheus-community/kube-prometheus-stack/87.19.2/effective-values-minimal.yamlnamespaceismonitoringreleaseNameiskube-prometheus-stackcapabilityProfileis{"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.
- kube-prometheus-stack-admission Declared. Not checked on any destination.
- 1.30.0 Declared. Not checked on any destination.
- monitoring Declared. Not checked on any destination.
This entry's plan, and how to test it
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.
- Before you deliver. Follow the certified CRD ordering route and wait for the ten retained CRDs before the ordinary platform objects. Who: delivery workflow. Recorded as routed.
- Before you deliver. Follow the certified lifecycle route to create or retain the target-owned admission Secret before webhook readiness checks. Who: delivery workflow. Recorded as routed.
- After you deliver. Follow the certified lifecycle route to patch the admission webhook after the operator and Secret exist, then check readiness. Who: delivery workflow. Recorded as routed.
- When you deliver. Apply the 10 CustomResourceDefinition objects first. Wait until every named definition reports the Established condition. The listing gives the rest. Who: whatever applies the objects. Written down. Not run by the Catalog.
- Once the destination is known. The chart defines 7 hook object(s) that do not travel in a flattened bundle, so the work they do has to happen some other way. A recorded run installed this base without them and watched that work happen as the ordered actions below. The listing gives the rest. Who: whatever applies the objects. Seen in a recorded run.
- Once the destination is known. The target-owned admission certificate must exist and its CA must be patched into all webhook configurations before admission is ready. The retained manual lifecycle observation records creation, patching and readiness checks. The listing gives the rest. Who: whatever applies the objects. Seen in a recorded run.
Test the plain objects yourself. This script tests the retained objects themselves with kubectl, and it needs no cub and no account. Read it first and use a throwaway cluster. The Catalog has no recorded run of this script.
1. Get the exact objects Run for this entry
The Catalog rendered this entry and retains its 24 objects in one file.
# fetch the retained objects for this entry
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-19-2-minimal.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/runs/prometheus-operator-minimal-candidate/recipes/prometheus-community/kube-prometheus-stack/87.19.2/revisions/minimal/r001/rendered/release-objects.yaml
# check the bytes against the listing
$ shasum -a 256 prometheus-community-kube-prometheus-stack-87-19-2-minimal.yaml
9947d9f86e3cabce7870b80560cda7ffd0381a909d253c43c6120f56c0b5a78c prometheus-community-kube-prometheus-stack-87-19-2-minimal.yaml
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 3 other bases in the Catalog, default, existing-secret and no-crds. The Catalog holds 5 other versions, 84.4.0, 85.3.3, 86.1.0, 87.15.1 and 88.6.3.
# fetch the default base of the same version
$ 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 differs between the two bases
$ cub config diff prometheus-community-kube-prometheus-stack-87-19-2-minimal.yaml prometheus-community-kube-prometheus-stack-87-19-2-default.yaml --summary
# fetch the default base at version 87.15.1
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-15-1-default.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.15.1/revisions/default/r001/rendered/release-objects.yaml
# list what changed from 87.15.1 to 87.19.2
$ cub config diff prometheus-community-kube-prometheus-stack-87-15-1-default.yaml prometheus-community-kube-prometheus-stack-87-19-2-minimal.yaml --summary
3. Upload it as a variant Not run for this entry
The Catalog has not uploaded this entry. The commands use its published literal configuration bundle.
# sign in; steps 3 to 5 write to your ConfigHub organization
$ cub auth login
# preview the upload of the published bundle; nothing is written
$ cub variant upload --dry-run --component prometheus-community-kube-prometheus-stack --variant minimal --space prometheus-community-kube-prometheus-stack-87-19-2-minimal oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bundles/catalog-prometheus-community-kube-prometheus-stack-87-19-2-minimal:latest@sha256:194fa0207e199e7f5b834583ac06495d05cd3d84c1ed5dc0fc5936d854975bb1
# upload the bundle as a base Space of Units
$ cub variant upload --component prometheus-community-kube-prometheus-stack --variant minimal --space prometheus-community-kube-prometheus-stack-87-19-2-minimal oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bundles/catalog-prometheus-community-kube-prometheus-stack-87-19-2-minimal:latest@sha256:194fa0207e199e7f5b834583ac06495d05cd3d84c1ed5dc0fc5936d854975bb1
4. Deploy it Not run for this entry
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 3 inputs that the destination must supply, so read them before you deploy.
# clone the base onto a Target as a dev variant
$ cub variant create dev prometheus-community-kube-prometheus-stack-87-19-2-minimal --target workshop/target --space-pattern "template:prometheus-community-kube-prometheus-stack-87-19-2-minimal-dev"
# publish the Release that Argo CD or Flux pulls
$ cub release publish prometheus-community-kube-prometheus-stack-87-19-2-minimal-dev
5. Promote a change Not run for this entry
No 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.
# preview what the dev variant would take from the base
$ cub variant promote prometheus-community-kube-prometheus-stack-87-19-2-minimal-dev --dry-run -o mutations
# promote once you have read the preview
$ cub variant promote prometheus-community-kube-prometheus-stack-87-19-2-minimal-dev --change-desc "Pull the reviewed base forward"
Helm chart, base no-crds, version 87.19.2
What is fixed, and what you supply
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.
chartisprometheus-community/kube-prometheus-stackversionis87.19.2baseisno-crdsvaluesProfileisrecipes/prometheus-community/kube-prometheus-stack/87.19.2/effective-values-no-crds.yamlnamespaceismonitoringreleaseNameiskube-prometheus-stackcapabilityProfileis{"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.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator CRD managed outside this no-crds preset. package://prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml Declared. Not checked on any destination.
- Prometheus Operator admission webhook TLS material created by the packaged chart-specific setup Job. package://prerequisites/kube-prometheus-stack-lifecycle/prepare.sh Declared. Not checked on any destination.
This entry's plan, and how to test it
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.
- Before you deliver. The no-crds render omits CRDs, so the package applies the locked CRDs before the workload. Who: cub installer package script. Recorded as routed.
- After you deliver. The run removes both completed Jobs and their temporary RBAC objects. Who: delivery workflow. Recorded as routed.
- After you deliver. The package runs the chart's webhook patch Job after the webhook objects exist. Who: delivery workflow. Recorded as routed.
- Before you deliver. The package runs the chart's certificate creation Job before applying the admission webhooks. Who: delivery workflow. Recorded as routed.
- Around an upgrade. Argo CD and Flux upgraded the no-crds preset from 85.3.3 to 86.1.0, reran the four ordered stages, replaced both hook Jobs, and passed the runtime checks. Who: delivery workflow. Recorded as routed.
- Before you deliver. The direct runner applies CRDs, creates the certificate, applies the workload, and patches the webhooks in that order. Who: delivery workflow. Recorded as routed.
- Before you deliver. The certificate Job creates the required admission Secret with ca, cert, and key. Who: operator. Recorded as routed.
- After you deliver. The run checks three CA bundles, the operator endpoint, a server dry-run, and six workloads. Who: delivery workflow. Recorded as routed.
1. Get the exact objects Run for this entry
The Catalog rendered this entry and retains its 115 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.
# fetch the retained objects for this entry
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-19-2-no-crds.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.19.2/revisions/no-crds/r001/rendered/release-objects.yaml
# check the bytes against the listing
$ shasum -a 256 prometheus-community-kube-prometheus-stack-87-19-2-no-crds.yaml
86d54113ec12fcea838d30e7e2ff6722de375bd0f6cc0e09ab8a14078c941446 prometheus-community-kube-prometheus-stack-87-19-2-no-crds.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:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987 --base no-crds --work-dir ./prometheus-community-kube-prometheus-stack-87-19-2-no-crds --non-interactive --namespace monitoring
2. Compare with another version or base Not run for this entry
The listing records no comparison for this entry. The commands run on the retained files, with no account. This version has 3 other bases in the Catalog, default, existing-secret and minimal. The Catalog holds 5 other versions, 84.4.0, 85.3.3, 86.1.0, 87.15.1 and 88.6.3.
# fetch the default base of the same version
$ 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 differs between the two bases
$ cub config diff prometheus-community-kube-prometheus-stack-87-19-2-no-crds.yaml prometheus-community-kube-prometheus-stack-87-19-2-default.yaml --summary
# fetch the no-crds base at version 87.15.1
$ curl -fsSL -o prometheus-community-kube-prometheus-stack-87-15-1-no-crds.yaml https://raw.githubusercontent.com/confighub/helm-expt/main/recipes/prometheus-community/kube-prometheus-stack/87.15.1/revisions/no-crds/r001/rendered/release-objects.yaml
# list what changed from 87.15.1 to 87.19.2
$ cub config diff prometheus-community-kube-prometheus-stack-87-15-1-no-crds.yaml prometheus-community-kube-prometheus-stack-87-19-2-no-crds.yaml --summary
3. Upload it as a variant Not run for this entry
The 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-87-19-2-no-crds --space <your-space> --component <your-component>
# list the Units the upload created
$ cub unit list --space <your-space>
4. Deploy it Not run for this entry
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 11 inputs that the destination must supply, so read them before you deploy. 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>-dev
5. Promote a change Not run for this entry
No 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>-dev
Available Configurations
default- package defaultno-crdsexisting-secret
The section below says what these configurations expect you to provide.
Local Configuration Checks
We ran cub check v0.7.3 against the exact rendered objects for every configuration below. The result is advisory: read each finding and decide whether it matters for your target.
Scanner and ruleset identity
Pattern bundle: v0.7.3
Bundle manifest: sha256:0405f6ffe21e567adf5d6a732d181c7f228194920456d046b4338baeb14de1a8
Risk catalog: sha256:7ff79a126ad99bba2505fec8b2b7711c03f50eb362141128ec1c83e27a5036ba
| Configuration | Advisory result | Exact input | Checked | Evidence |
|---|---|---|---|---|
default | 25 advisory findings 5 critical, 16 warning, 4 info ClusterRole grants secrets read permissions Thanos sidecar not uploading blocks Deployment containers omit resource limits | 125 objectssha256:f9a976944a7addb825e0dbb6ce6b3d0ebc43b2b5487211f7eb9b169f06d7aaef | 2026-09-16 | Full cub check resultExact YAML Separate Catalog review |
existing-secret | 25 advisory findings 5 critical, 16 warning, 4 info ClusterRole grants secrets read permissions Thanos sidecar not uploading blocks Deployment containers omit resource limits | 124 objectssha256:6a04712c9f61cad037c48464916f3f1d69c9d2330eb0be03ff75ded015a45f40 | 2026-09-16 | Full cub check resultExact YAML Separate Catalog review |
no-crds | 25 advisory findings 5 critical, 16 warning, 4 info ClusterRole grants secrets read permissions Thanos sidecar not uploading blocks Deployment containers omit resource limits | 115 objectssha256:b05b4ca66b6785ad7cebf692a9a13f72b9397aea35f7d88ca2c400516e63115b | 2026-09-16 | Full cub check resultExact YAML Separate Catalog review |
What this does not check: hook execution, CRD readiness, target Secrets and cloud services, admission behavior, workload health, or rollback. The linked Catalog review covers chart-specific source and operating questions. ConfigHub validation and approval are separate managed controls.
Read all shared check results and the mapping to Catalog rules.
What This Chart Contains
Shipping a chart as plain rendered YAML is faster and simpler, and it silently drops anything Helm was going to do afterwards. This section reports what a scan of the packaged chart found, across 286 files.
| Construct | Found | Why it matters when a chart ships as plain YAML |
|---|---|---|
| Helm hooks | 16 | Hook Jobs never fire, or fire under a different hook dialect. |
| Cluster lookups | 4 | The chart reads the cluster while rendering, so a render without one is valid but wrong. |
| Webhook configuration | 2 | An empty certificate bundle makes admission fail closed. |
| Capability branching | 86 | The chart chooses apiVersions from the cluster it renders against. |
| Generated credentials | 2 | Every render mints new values, and a shared artifact would freeze one draw. |
| Custom resource definitions | 18 | Per-file delivery can race the definitions the resources depend on. |
| Condition-gated subcharts | 5 | What renders depends on which conditions the values switch on. |
A flattening-safety verdict has decided this version: default:unsafe-to-flatten; existing-secret:unsafe-to-flatten; no-crds:unsafe-to-flatten. The verdict records one disposition per construct and names any companion artifact a flattened bundle must ship. What the flattening verdict means.
A construct being present does not make a chart unflattenable. Most are switched on or off by values, and a verdict records which ones the base you choose actually reaches. Read the catalog-wide evidence for how common each one is.
Images This Chart Pulls
Every reference below is read from the committed package bases, so what you see is what the packaged manifests name.
| Packaged base | Image references |
|---|---|
| default | description: image defines Thanos container image URL.description: |-docker.io/grafana/grafana:13.1.1quay.io/kiwigrid/k8s-sidecar:2.8.1quay.io/prometheus-operator/prometheus-operator:v0.92.1quay.io/prometheus/alertmanager:v0.33.1quay.io/prometheus/node-exporter:v1.12.1-distrolessquay.io/prometheus/prometheus:v3.13.1-distrolessregistry.k8s.io/kube-state-metrics/kube-state-metrics:v2.19.1 |
| no-crds | docker.io/grafana/grafana:13.1.1quay.io/kiwigrid/k8s-sidecar:2.8.1quay.io/prometheus-operator/prometheus-operator:v0.92.1quay.io/prometheus/alertmanager:v0.33.1quay.io/prometheus/node-exporter:v1.12.1-distrolessquay.io/prometheus/prometheus:v3.13.1-distrolessregistry.k8s.io/kube-state-metrics/kube-state-metrics:v2.19.1 |
| existing-secret | description: image defines Thanos container image URL.description: |-docker.io/grafana/grafana:13.1.1quay.io/kiwigrid/k8s-sidecar:2.8.1quay.io/prometheus-operator/prometheus-operator:v0.92.1quay.io/prometheus/alertmanager:v0.33.1quay.io/prometheus/node-exporter:v1.12.1-distrolessquay.io/prometheus/prometheus:v3.13.1-distrolessregistry.k8s.io/kube-state-metrics/kube-state-metrics:v2.19.1 |
What Has Been Tested
Choose the question you care about. Not checked means this catalog has no version-specific result; it is not a pass.
| Question | Status | Evidence |
|---|---|---|
| Can I pull these exact package bytes again? | Checked | Package receipt |
| What does this chart contain? | Not checked | No linked result |
| Does the recorded render match Helm? | Not checked | No linked result |
| Did the supplied values change the render? | Not checked | No linked result |
| Were hooks, CRDs, or setup steps checked? | Not checked | No linked result |
| Did this version run on a local Kubernetes cluster? | Not checked | No linked result |
| Did an OCI delivery through GitOps run? | Not checked | No linked result |
| Did Helm and ConfigHub reach the same live result? | Not checked | No linked result |
| Was the result compared on separate clusters? | Not checked | No linked result |
| Was a ConfigHub promotion tested? | Not checked | No linked result |
| Did this version string point at changed upstream bytes? | Not checked | No linked result |
The committed publication receipt binds this package path and OCI ref to layer sha256:677058d72313c3c124a4eea80a280d5a1f63145d09079f6f3a8565c9d9c33ca4 and manifest sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987, and records an inspect-result digest.
You can check a pull yourself: the inspect command under Try This Chart prints the package's manifest and layer digests, and they must equal the receipted values above. If they differ, do not use the pulled package.
No version-specific runtime result is claimed here. The component row's readiness, caveats, and live evidence describe only its bold version. For that separate evidence, open the 85.3.3 evidence page.
What You Must Provide
The installer metadata records 34 external-requirement references across these configurations. Inspect the package before choosing a base.
Choose a namespace and target deliberately, supply any listed Secret, CRD, storage, API, or cloud prerequisite, and inspect the rendered YAML before delivery.
Before Production
Run target-specific policy, lifecycle, upgrade, and workload checks. A successful package publication and inspect result does not establish production support or live convergence.
Source And Evidence Files
| Record | Open |
|---|---|
| Retained package source | packages/prometheus-community/kube-prometheus-stack/87.19.2 |
| Machine-readable listing (default) | site/listings/prometheus-community-kube-prometheus-stack-87-19-2-default.json |
| Machine-readable listing (no-crds) | site/listings/prometheus-community-kube-prometheus-stack-87-19-2-no-crds.json |
| Machine-readable listing (existing-secret) | site/listings/prometheus-community-kube-prometheus-stack-87-19-2-existing-secret.json |
| Installer metadata | packages/prometheus-community/kube-prometheus-stack/87.19.2/installer.yaml |
| Publication receipt | runs/installer-oci/prometheus-community-kube-prometheus-stack/87.19.2/installer-package-publication-receipt.yaml |
| Publisher signature | runs/installer-oci-signatures/prometheus-community-kube-prometheus-stack/87.19.2/signature-receipt.yaml |
| Sigstore bundle | runs/installer-oci-signatures/prometheus-community-kube-prometheus-stack/87.19.2/signature.sigstore.json |
| Version tag | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:87.19.2 |
| Exact OCI ref | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:87.19.2@sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987 |
| Layer digest | sha256:677058d72313c3c124a4eea80a280d5a1f63145d09079f6f3a8565c9d9c33ca4 |
| Manifest digest | sha256:df91aefaac87edd2bcd625ec9a87f7142d49fc2d7ffc70878dfb1d92bc885987 |
Technical notes and disclaimers
- default, existing-secret, no-crds. The Catalog publishes no plain objects for this entry, because its verdict is unsafe-to-flatten. It has no plain-objects test.
- minimal. The plain-objects script stops before it applies anything. 3 steps of the plan are yours to do first, and it prints them. When you run it again it applies the objects and ends. It does not wait for the workloads to start. The script does not run the steps the plan names for an upgrade or a delete.