See what the kube-prometheus-stack Helm chart becomes

1. See what you have today

You have the kube-prometheus-stack chart 88.6.3 with the values of the Catalog's default base, shown in values.yaml. Helm renders it like this, and the Workshop's check reads the result.

before: plain helm template

$ helm template kube-prometheus-stack kube-prometheus-stack --repo https://prometheus-community.github.io/helm-charts --version 88.6.3 --namespace monitoring -f values.yaml --kube-version 1.30.0 > before.yaml
$ cub config check before.yaml
Config: before
Inspecting local Kubernetes objects (static, no infrastructure)

Installs
  122 objects: 1 Alertmanager, 5 ClusterRole, 5 ClusterRoleBinding, 32 ConfigMap, 1 DaemonSet, 3 Deployment, 2 Job, 1 MutatingWebhookConfiguration, 1 Prometheus, 35 PrometheusRule, 1 Role, 1 RoleBinding, 2 Secret, 11 Service, 7 ServiceAccount, 13 ServiceMonitor, 1 ValidatingWebhookConfiguration
  namespaces that must already exist: kube-system, monitoring

Lifecycle work
  [PASS] CRDs: 0
  [NOTE] Helm hooks: 7
  [NOTE] setup Jobs: 2
  [NOTE] admission webhooks needing a certificate: 2
  [PASS] images tagged latest or not tagged: 0

Schema
  [PASS] schema validation: 122 object(s) valid against the default and ecosystem catalogs (flux-schema/0.16.0)

  Free look before you install. Compose it into a cub stack, or run it as a cub app.

The 7 hook objects sit in the same file as everything else. Apply the file and they run at once, outside the order Helm gives them.

Kind	Name	Helm hook
ServiceAccount	`kube-prometheus-stack-admission`	`pre-install,pre-upgrade,post-install,post-upgrade`
ClusterRole	`kube-prometheus-stack-admission`	`pre-install,pre-upgrade,post-install,post-upgrade`
ClusterRoleBinding	`kube-prometheus-stack-admission`	`pre-install,pre-upgrade,post-install,post-upgrade`
Role	`kube-prometheus-stack-admission`	`pre-install,pre-upgrade,post-install,post-upgrade`
RoleBinding	`kube-prometheus-stack-admission`	`pre-install,pre-upgrade,post-install,post-upgrade`
Job	`kube-prometheus-stack-admission-create`	pre-install,pre-upgrade
Job	`kube-prometheus-stack-admission-patch`	post-install,post-upgrade

The file holds none of the chart's 10 CRDs. They sit in its crds folder, which helm template leaves out. Helm installs them on the first install only, and never upgrades them.

2. See what the Workshop gives you

The Catalog keeps the objects of its default base for this chart, and a plan for everything that is not an object to apply.

after: the default base

$ cub config check after.yaml
Config: after
Inspecting local Kubernetes objects (static, no infrastructure)

Installs
  125 objects: 1 Alertmanager, 4 ClusterRole, 4 ClusterRoleBinding, 32 ConfigMap, 10 CustomResourceDefinition, 1 DaemonSet, 3 Deployment, 1 MutatingWebhookConfiguration, 1 Prometheus, 35 PrometheusRule, 2 Secret, 11 Service, 6 ServiceAccount, 13 ServiceMonitor, 1 ValidatingWebhookConfiguration
  namespaces that must already exist: kube-system, monitoring

Lifecycle work
  [NOTE] CRDs: 10 (apply and establish before any custom resource)
  [PASS] Helm hooks: 0
  [PASS] setup Jobs: 0
  [NOTE] admission webhooks needing a certificate: 2
  [PASS] images tagged latest or not tagged: 0

Schema
  [PASS] schema validation: 125 object(s) valid against the default and ecosystem catalogs (flux-schema/0.16.0)

  Free look before you install. Compose it into a cub stack, or run it as a cub app.

The plan has 19 steps.

Step	What it is	What it says
`preflight-or-presync-crd-apply`	a step of the apply	The package applies the locked CRDs before the chart objects that use them.
`preserve-cleanup-policy`	a step of the apply	The run removes both completed Jobs and their temporary RBAC objects.
`postsync-check-or-observation`	a step of the apply	The package runs the chart's webhook patch Job after the webhook objects exist.
`preflight-or-presync`	a step of the apply	The package runs the chart's certificate creation Job before applying the admission webhooks.
`upgrade-action-with-receipt`	a step of the apply	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 removed the temporary Jobs.
`preserve-ordering`	a step of the apply	The direct runner applies CRDs, creates the certificate, applies the workload, and patches the webhooks in that order.
`target-facts-or-preflight`	a step of the apply	The certificate Job creates the required admission Secret with ca, cert, and key.
`webhook-readiness-observation`	a step of the apply	The run checks three CA bundles, the operator endpoint, a server dry-run, and six workloads.
`alertmanagerconfigs.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`alertmanagers.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`podmonitors.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`probes.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`prometheusagents.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`prometheuses.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`prometheusrules.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`scrapeconfigs.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`servicemonitors.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`thanosrulers.monitoring.coreos.com`	must exist on the target	Prometheus Operator CRD included in this preset and applied before dependent objects
`monitoring/kube-prometheus-stack-admission`	must exist on the target	Prometheus Operator admission webhook TLS material created by the packaged chart-specific setup Job

3. See what changed

	Before, helm template	After, the default base
Objects	122	125
Helm hook objects in the file	7	0
CRDs	0	10
Objects that are the same on both sides	115	115
Plan steps	none	19

4. Try it yourself, with no account

Install cub and the Workshop plugin first.

# before: render the chart as Helm does
$ helm template kube-prometheus-stack kube-prometheus-stack --repo https://prometheus-community.github.io/helm-charts --version 88.6.3 --namespace monitoring -f values.yaml --kube-version 1.30.0 > before.yaml

$ cub config check before.yaml

# after: fetch the objects the Catalog keeps for this base
$ curl -fsSL -o after.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

$ cub config check after.yaml

Save values.yaml next to the commands first.

The entry page shows the plan and every other base of this chart.

See it live in ConfigHub

Everything above runs on your own machine with no account. To see the same example in ConfigHub, load it into your own organization with the commands below.

With your own account

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.

# render the base from the signed package
$ 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 monitoring

# sign in to your organization
$ cub auth login

# load the objects 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 what was loaded
$ cub unit list --space <your-space>

What it looks like in ConfigHub

ConfigHub showing the Prometheus object, at its image line — The helm-catalog organization on 2026-10-25, showing the Prometheus object, at its image line. It was loaded as this panel describes.

5. Technical notes and disclaimers

Both checks ran on 2026-10-26 with cub v0.9.0, Workshop plugin 0.6.61 and helm v4.1.4+g05fa379. The recorded files and their receipt hold every input and output on this page.
Both sides render for Kubernetes 1.30.0, as the Catalog does, so only the handling differs.
No step of the plan has been run on a cluster for this page. The plan says what a delivery workflow must do, and nothing runs it automatically.