prometheus-community/kube-prometheus-stack 85.3.3 - no-crds

A repository document, rendered for the site. View source markdown.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

This guide explains the journey from a public Helm chart to a ConfigHub Space. Use it when you want to know why this preset exists, what problem it solves, how to repeat it, and what still needs care.

It is generated from the same records that build the package, chart page, render intent, scripts, and receipts. The proof links are lower down.

Why this preset exists

Helm charts often expose many settings, but a values file alone does not tell the whole operations story. A team still needs to know what Kubernetes objects will be created, which Secrets or CRDs must already exist, whether hooks or setup jobs need special handling, and what evidence backs the result.

This preset is a named answer for one useful operating choice. It keeps the upstream chart, records the inputs and rendered YAML, and gives the team a repeatable starting point instead of a private values-file guess.

What this is

This is the no-crds preset config for prometheus-community/kube-prometheus-stack@85.3.3. The repo also calls this a base variant. Use this when your platform, GitOps bootstrap, or another chart owns the CRDs.

The matching catalog page is prometheus-community/kube-prometheus-stack@85.3.3.

The chart journey

We keep the Helm chart. We lock prometheus-community/kube-prometheus-stack@85.3.3, choose the no-crds preset config, render it with the recorded values, namespace, release name, and Kubernetes capabilities, then save the output as files.

That captured output is the render variant: recipes/prometheus-community/kube-prometheus-stack/85.3.3/revisions/no-crds/r001/rendered/release-objects.yaml. It contains 114 Kubernetes object(s): PrometheusRule x35, ConfigMap x31, ServiceMonitor x13, Service x11, ServiceAccount x6, ClusterRole x4, ClusterRoleBinding x4, Deployment x3.

The public package is oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3. Users can pull it without cloning this repo. When someone runs cub installer upload, ConfigHub stores the rendered Kubernetes YAML in a Space so it can be searched, compared, reviewed, changed, and delivered. The example script defaults to Space helm-kube-prometheus-stack-no-crds, but users can choose another name with CUB_SPACE=....

What to check

This preset config records 11 prerequisites: 10 CRDs, 1 Secret. Follow the instructions below before you apply the rendered objects.

The catalog records 7 extra steps for this preset. We call these lifecycle routes because they say what must happen before, during, or after Kubernetes applies the main set of files.

CRDs are made into an explicit choice instead of being mixed into the application install. CRD ownership is recorded as part of the preset config. Some CRDs must already exist before the rendered objects are applied. At least one Secret must be created with your values before apply. Hooks, setup jobs, and other install or upgrade steps are listed separately, so you can see what must run and when. Known limitation: existing-secret (chart ships no Secret toggle).

Why you can trust it

This is a claim about this recorded preset config. It is not a claim that every possible values file for this chart has been checked.

Repeat it

Fast path with no ConfigHub account:

bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/prometheus-community-kube-prometheus-stack-85-3-3/no-crds/try.sh)

Fast path with a ConfigHub account:

bash <(curl -fsSL https://confighub.github.io/helm-expt/site/sh/prometheus-community-kube-prometheus-stack-85-3-3/no-crds/confighub.sh)

The core render command is:

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 --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3 --base no-crds --work-dir ./prometheus-community-kube-prometheus-stack-85-3-3-no-crds --non-interactive --namespace monitoring

After upload, create environment versions with cub variant create and move reviewed changes with cub variant promote. The walkthrough is After Upload: Create A Variant And Promote Changes.

Preset details

ItemValue
Chartprometheus-community/kube-prometheus-stack@85.3.3
Preset configno-crds
Namespacemonitoring
Release namekube-prometheus-stack
Valuesrecipes/prometheus-community/kube-prometheus-stack/85.3.3/effective-values-no-crds.yaml
Render intentdata/helm-render-intents/intents/prometheus-community-kube-prometheus-stack-85-3-3-no-crds.yaml
Render variantrecipes/prometheus-community/kube-prometheus-stack/85.3.3/revisions/no-crds/r001/rendered/release-objects.yaml
Package basepackages/prometheus-community/kube-prometheus-stack/85.3.3/bases/no-crds
Scriptstry.sh · confighub.sh

Prerequisites and lifecycle steps

WhenWhatHow it is handled
Before installClusterFeature: Secret monitoring/kube-prometheus-stack-admission keys cert,keykubectl -n monitoring create secret generic kube-prometheus-stack-admission --from-literal=cert=<value> --from-literal=key=<value>
Before install10 CRDs: alertmanagerconfigs.monitoring.coreos.com, alertmanagers.monitoring.coreos.com, podmonitors.monitoring.coreos.com, probes.monitoring.coreos.com, prometheusagents.monitoring.coreos.com, prometheuses.monitoring.coreos.com, prometheusrules.monitoring.coreos.com, scrapeconfigs.monitoring.coreos.com, servicemonitors.monitoring.coreos.com, thanosrulers.monitoring.coreos.comIncluded in the public package as prerequisites/target-facts/no-crds-crds.yaml. The generated try script applies it and waits for the required CRD before installing the main objects.
Before installPrepare the targetpreflight-or-presync.
Before installKeep the required apply orderpreserve-ordering.
Before installPrepare the targettarget-facts-or-preflight.
After installCheck the completed installpostsync-check-or-observation.
After installWait for the webhook to be readywebhook-readiness-observation.
During upgradeRun the upgrade stepupgrade-action-with-receipt.
When uninstallingKeep the chart's cleanup policypreserve-cleanup-policy.

Evidence

CheckStatus
Render parityyes
ConfigHub scan/upload proofyes
Earlier local-cluster testyes
GitOps OCI live runyes
Live Helm vs ConfigHub comparisonyes
Lifecycle routes7

Limits

Source files