What this page gives you
Every chart page follows the same order. Choose a configuration, inspect its objects and setup work, then read the tests that have run. Open the worked examples.
The package fixes and checks almost everything at build time. What you set is small and typed.
Open the saved results for the Helm comparison, live install, and delivery checks.
The page names the work and says which delivery path has actually run.
What To Use
default configuration: 124 rendered objects · 9 images · 11 target prerequisites · 8 hook or setup routes · 6/6 checks passing. These counts come from the linked test records.
defaultRecommended first base variant
2Supported base variants
Rendering checked; read the chart pageFirst-configuration status
Ready for a target-specific production reviewProduction status
Use the public catalog entry, then check the exact configuration and its tests before making a production claim.
| Question | Answer |
|---|
| Catalog readiness | Ready to try |
| Chart version | 85.3.3 |
| Exact installer package | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85 |
| OCI publication status | publication receipt recorded |
| Publisher signature | publisher signature recorded and verified |
| Latest upstream seen | 86.1.0 (update candidate) |
| Supported base variants | default;no-crds |
| Not yet available | No specific missing capability is recorded. The first configuration still needs review. |
| Namespace | monitoring |
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? | A destination-specific lifecycle plan is recorded for the named target and delivery runtime. | Destination access: yes
Selected configuration deployed: no | Checked: passed
evidence recorded |
| 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.
Where This Chart's Settings Come From
| 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. | 11 prerequisites and 8 hook or setup routes recorded. |
| no-crds | effective-values-no-crds.yaml | None in the catalog base. Later edits appear in ConfigHub Unit revision history or a derived variant. | 11 prerequisites and 8 hook or setup routes recorded. |
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. For the staging commands behind each prerequisite, open the prerequisite action packets.
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 283 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 | 85 | 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; no-crds:unsafe-to-flatten. The verdict records one disposition per construct and names any companion artifact a flattened bundle must ship.
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.
What The Starting Configuration Records
A base variant is a starting configuration we have already rendered and checked. Pick the one whose trade-off you want; the table below shows what each one changes. How the values for each are chosen.
The default base-variant record connects those Helm inputs to the Kubernetes objects, remaining requirements, hooks, CRDs, checks, and OCI status. Open it when you need the complete starting record rather than only the rendered YAML.
Open the full rendered YAML to read the actual manifest output. The render record and setup section explain the inputs, tests, CRDs, hooks, and other work around it.
If new Helm values create a useful starting configuration, record another base variant with its own inputs and checks. If one environment changes a field after rendering, record that change in a ConfigHub variant.
| 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-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85 | The exact installer package for this chart version. The version tag is readable, and the manifest digest makes a published pull immutable. 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 | 10 CRDs
Included in the OCI package as prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml. It refreshes the locked CRDs with the chart's server-side, force-conflicts apply mode. The generated try script runs this step before the workload and waits for every CRD to become established.
Secret monitoring/kube-prometheus-stack-admission keys ca,cert,key
Included in the OCI package as prerequisites/kube-prometheus-stack-lifecycle/prepare.sh. The generated try script leaves complete existing Secrets under their current owner; otherwise it runs the packaged setup action and checks every required key before the workload. | 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 | default render intent | The Helm inputs and evidence links that explain how the output was produced. |
| Complete starting record | default base-variant record | The record that connects the Helm inputs, Kubernetes objects, remaining requirements, setup work, checks, and OCI status. |
| Hooks, CRDs, and setup work | this page's setup section | Instructions and decisions for hooks, CRDs, generated Secrets, setup jobs, cluster requirements, 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, namespace, release name, source lock, default render intent, full YAML output, package base, test results, and setup instructions 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
Try This Chart
Start with default. If a card says review or preparation is needed, treat that as a real limit rather than a ready install.
Package image
Exact package: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85
publication receipt recorded · open the exact publication receipt
Readable version tag: oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3. The package is pinned so a republished tag cannot change what you get. The command below uses the exact manifest digest, so cub installer refuses different package bytes.
Check the package identity
New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.
cub installer inspect oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85 --json
Read how each configuration was made
cub installer pull 'oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85' --work-dir ./package-review
less ./package-review/package/records/README.md
The package's records/ directory connects every base to its source choices, Helm render intent, Kubernetes objects, prerequisites, lifecycle work, and checks. These are supporting records, not Kubernetes objects.
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/85.3.3 --annotations confighub.com/package-sha256=66d9cb2b416e82196b07c391aaca6b8d47a024bef269b2ca91852a0515fd11b1 europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85
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
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-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85 --base default --work-dir ./prometheus-community-kube-prometheus-stack-85-3-3-default --non-interactive --namespace monitoring
Advanced: apply it or upload it
Run the whole sequence as one script, prerequisites included: try.sh renders and applies to Kubernetes without an account; confighub.sh renders and uploads to your ConfigHub Space.
Before you run try.sh: it changes your current kubectl context. It runs the named prerequisites and applies the rendered objects. Read it first and use a disposable test cluster. confighub.sh does not apply anything to Kubernetes.
You should see something like this
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 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: Promotion was tested and recorded in ConfigHub.
After You Render It
The first command writes files and does not apply them. Read the objects and setup requirements, then choose the next job.
| Job | Next step |
|---|
| Render and inspect without applying | Run the recommended cub installer setup command above. |
| Run shared local configuration checks | 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. |
| Apply the rendered manifests with kubectl, or publish reviewed objects as OCI | Publish reviewed objects as OCI or apply the manifests with kubectl. |
| Save the reviewed result for a team | Save and upload the reviewed result to ConfigHub for shared history, exact diffs, and approvals. |
| Compare development and production, audit an exact diff, promote, or roll back | Build a promotion review or read the bounded rollback example. |
| Assign the configuration to clusters and operate a small fleet | Choose targets, preview a wave, and inspect every result. |
| Check delivery limits | Read the current limits before choosing kubectl, Argo CD, or Flux. |
| Handle CRDs on the first install | Read the CRD ordering risk and first-install guide, then check this chart's recorded owner and route. |
Serious Chart Example
kube-prometheus-stack is the serious-chart example. Its fresh install needs ten CRDs, certificate setup, webhook patching, ordinary Kubernetes objects, readiness checks, and cleanup in a particular order.
What to look for
| Area | Why it matters |
|---|
| CRDs | CRDs must be installed and upgraded in the right order. A matching render does not prove that. |
| Webhooks | Admission webhooks need working certificates and must be ready before dependent resources are applied. |
| Cluster requirements | Storage, APIs, and other cluster capabilities determine whether the objects can run. |
| Watch results | A Watch result tells you which deployment question is still open. |
The public package has run that full fresh-install sequence. A separate isolated client pulled the same package with no ConfigHub account or registry login and received all nine lifecycle files. The default base then upgraded through the same direct package route to 86.1.0, retained the admission Secret, reran the lifecycle steps, and reached all six checked workloads. The no-crds base also ran from one staged OCI digest through Argo CD and Flux on separate fresh clusters, then upgraded to the 86.1.0 staged digest. ConfigHub does not yet select the route automatically. These receipts do not prove rollback or long-running soak.
Open the package lifecycle proof · Open the direct upgrade proof · Open the Argo CD and Flux proof · Check the anonymous pull · Read the hooks and CRDs guide · Open serious chart proof
Available Configurations
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.
Checks: Each card names what was checked and says whether it passed, needs review, was blocked, was not run, or was not needed.
3 matrix rows for prometheus-community/kube-prometheus-stack@85.3.3 · open the full matrix
F1 · Source chart
(source)
Source
Pinned upstream chart and version
- 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
- 2 source hooks; hook route: observed; live action receipt: yes; packaged setup: prerequisites/kube-prometheus-stack-lifecycle/prepare.sh, prerequisites/kube-prometheus-stack-lifecycle/finish.sh
- Who runs actions?
- The generated try script runs each packaged step at its recorded point. The no-crds base also has linked Argo CD and Flux receipts.
- Next
- Choose a chart configuration before rendering or deploying
- Reason
- This is the chart source. Choose a configuration before checking deployment or promotion
Helm outputNot neededSaved in ConfigHubNot neededLocal clusterNot neededSetup routeNot neededGitOps and OCINot neededLive Helm comparisonNot neededTwo clustersNot neededPromotionNot needed
catalog · source repo
F2a · Chart default
default
Base
Runnable base variant made from the chart defaults
- 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-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85 --base default --work-dir ./prometheus-community-kube-prometheus-stack-85-3-3-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
- 2 source hooks; hook route: observed; live action receipt: yes; 8 recorded lifecycle routes; packaged setup: prerequisites/kube-prometheus-stack-lifecycle/prepare.sh, prerequisites/kube-prometheus-stack-lifecycle/finish.sh
- Who runs actions?
- You or your delivery pipeline (8); the full record shows which delivery paths have receipts
- Lifecycle record
- 8 chart-specific lifecycle routes are recorded. The full record separates direct, Argo CD, and Flux handling and says which paths have actually run. Open the full record.
- Prerequisites
- 11 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
- Next
- Choose the target ready base; Then record explicit security acceptance or create a hardened base before claiming a target run path
- Reason
- Promotion was tested and recorded in ConfigHub.
Helm outputPassedSaved in ConfigHubPassedLocal clusterPassedSetup routePassedGitOps and OCIPassedLive Helm comparisonPassedTwo clustersNot runPromotionPassed
catalog · variant · full YAML · render intent · base record · package base · receipt · source repo
F2b · Helm-rendered base
no-crds
Base
Runnable base variant made with different Helm values
- Status
- Available in the catalog
- Helm values
- effective-values-no-crds.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-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85 --base no-crds --work-dir ./prometheus-community-kube-prometheus-stack-85-3-3-no-crds --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
- 2 source hooks; hook route: observed; live action receipt: yes; 8 recorded lifecycle routes; packaged setup: prerequisites/kube-prometheus-stack-lifecycle/prepare.sh, prerequisites/kube-prometheus-stack-lifecycle/finish.sh
- Who runs actions?
- You or your delivery pipeline (8); the full record shows which delivery paths have receipts
- Lifecycle record
- 8 chart-specific lifecycle routes are recorded. The full record separates direct, Argo CD, and Flux handling and says which paths have actually run. Open the full record.
- Prerequisites
- 11 prerequisites are declared for this base. Each prerequisite says whether it must be checked before render or before apply.
- Next
- Choose the target ready base; Then record explicit security acceptance or create a hardened base before claiming a target run path
- Reason
- Promotion was tested and recorded in ConfigHub.
Helm outputPassedSaved in ConfigHubPassedLocal clusterPassedSetup routePassedGitOps and OCIPassedLive Helm comparisonPassedTwo clustersNot runPromotionPassed
Demo README · catalog · variant · full YAML · render intent · base record · package base · receipt · source repo
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 | 124 objects
sha256:10e99260debc3b8209fc3a526cf52b8509edf73987bbf9d2a219b82737b8d49a | 2026-08-24 | Full cub check result
Exact 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 | 114 objects
sha256:3279b55feebc3b9c15238204e176892919a2220dc9b0b287d54657527101257d | 2026-08-24 | Full cub check result
Exact 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.
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 | description: image defines Thanos container image URL.
description: |-
docker.io/grafana/grafana:13.0.1-security-01
quay.io/kiwigrid/k8s-sidecar:2.7.3
quay.io/prometheus-operator/prometheus-operator:v0.90.1
quay.io/prometheus/alertmanager:v0.32.1
quay.io/prometheus/node-exporter:v1.11.1-distroless
quay.io/prometheus/prometheus:v3.11.3-distroless
registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.19.0 |
| no-crds | docker.io/grafana/grafana:13.0.1-security-01
quay.io/kiwigrid/k8s-sidecar:2.7.3
quay.io/prometheus-operator/prometheus-operator:v0.90.1
quay.io/prometheus/alertmanager:v0.32.1
quay.io/prometheus/node-exporter:v1.11.1-distroless
quay.io/prometheus/prometheus:v3.11.3-distroless
registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.19.0 |
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 and its pruning settings are recorded for the selected preset. |
| Shared placeholder password | No shared placeholder password caveat recorded for this chart. |
| CRD first-ordering | Yes. 10 CRDs must exist first. The public package contains the bootstrap, and its generated try.sh applies it and waits for the CRDs before installing the main objects. |
Open the all-chart adoption caveats · Helm to cub migration · cub deployment path
Advice And Current Status
Use this section to see which chart-specific guides apply, what you must provide, and what work remains.
| Playbook | Why it applies |
|---|
| Serious Chart Playbooks | a named hard chart, or one that combines CRDs and admission webhooks |
| Hook And Secret Lifecycle | uses Helm hooks, generated Secret material, or webhook certificates |
| Target Facts And Lifecycle | needs Secrets, CRDs, APIService readiness, storage, or generated runtime state before apply |
| Large App Evidence Funnel | renders many Units, so a single pass/fail can hide where an operation is stuck |
| Live Parity | has live, GitOps/OCI, or two-cluster parity work |
| Question | Current answer |
|---|
| User status | Ready to try |
| Can I use it? | Use the public catalog entry, then check the exact configuration and its tests. |
| First base | default |
| Exact installer package | oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/prometheus-community-kube-prometheus-stack:85.3.3@sha256:d2da5e6ee7bb7cebe256d494b67a05911b940d1a1c69793886a9e99e60112b85 |
| Tests completed | Catalog supported with live evidence (render parity 2/2; Local live 2/2; Live parity 2/2) |
| Coverage | Covered |
| You must provide | a StorageClass / storage decision; a CRD ownership choice (crds vs no-crds base); webhook/cert readiness at delivery time; target facts at variant time; mandatory chart inputs |
| What the tools record | exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; CRD handling split into explicit bases; hooks classified and routed (not silently executed); optional chart inputs handled by reviewed base configurations; install-vs-upgrade render divergence captured per revision; 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.
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.
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.
| Base | Readiness | Render | ConfigHub | Local live | GitOps/OCI | Live parity | Two-cluster kind |
|---|
| default | render-only | pass | pass | pass | pass | pass | missing |
| no-crds | render-only | pass | pass | pass | pass | pass | missing |
What You Must Provide
exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; CRD handling split into explicit bases; hooks classified and routed (not silently executed); optional chart inputs handled by reviewed base configurations; install-vs-upgrade render divergence captured per revision; cluster lookups lifted into declared target facts
| Field | Value |
|---|
| Known quirks | Hooks; Crds; Generated secrets; Webhooks; optional chart inputs; Install vs upgrade divergence; Required values; Lookup; Generated facts.; Tpl; Capabilities; Rbac; Storage |
| You must provide | a StorageClass / storage decision; a CRD ownership choice (crds vs no-crds base); webhook/cert readiness at delivery time; target facts at variant time; mandatory chart inputs |
| What ConfigHub records | exact rendered objects with render parity and receipts; generated Secrets separated out of the published artifact; CRD handling split into explicit bases; hooks classified and routed (not silently executed); optional chart inputs handled by reviewed base configurations; install-vs-upgrade render divergence captured per revision; cluster lookups lifted into declared target facts |
| Optional chart inputs | Raw/extra manifests; Monitoring config; Tpl powered values |
| How optional inputs are handled | 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.
What each base needs before apply
These requirements come from the same base definition as the rendered objects. The render intent keeps the chart inputs, required Secrets or CRDs, lifecycle routes, and evidence together.
| Base variant | Required resource | How to provide it | Full record |
|---|
| default | 10 CRDs | Included in the OCI package as prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml. It refreshes the locked CRDs with the chart's server-side, force-conflicts apply mode. The generated try script runs this step before the workload and waits for every CRD to become established. | full render intent |
| default | Secret monitoring/kube-prometheus-stack-admission keys ca,cert,key | Included in the OCI package as prerequisites/kube-prometheus-stack-lifecycle/prepare.sh. The generated try script leaves complete existing Secrets under their current owner; otherwise it runs the packaged setup action and checks every required key before the workload. | full render intent |
| no-crds | 10 CRDs | Included in the OCI package as prerequisites/kube-prometheus-stack-lifecycle/default-crds.yaml. It applies missing CRDs server-side. The generated try script leaves existing CRDs under their current owner and waits for them before the workload. | full render intent |
| no-crds | Secret monitoring/kube-prometheus-stack-admission keys ca,cert,key | Included in the OCI package as prerequisites/kube-prometheus-stack-lifecycle/prepare.sh. The generated try script leaves complete existing Secrets under their current owner; otherwise it runs the packaged setup action and checks every required key before the workload. | full render intent |
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.
Public package lifecycle: both 85.3.3 catalog bases passed fresh installs on separate, new kind clusters. The default base matched 124 checked chart objects; the no-crds base matched 114. Each run applied ten CRDs first, ran the chart's certificate and webhook patch Jobs, checked six workloads, and cleaned up. Argo CD and Flux then installed the 85.3.3 no-crds staged OCI and upgraded it to the 86.1.0 staged digest on separate clusters. Both replaced the completed setup Jobs and passed the runtime checks after upgrade. Open the default direct receipt, the no-crds direct receipt, the anonymous pull proof, or the Argo CD and Flux proof. The controller receipt is limited to this version pair and does not prove rollback, long soak, or automatic ConfigHub route selection.
Managed promotion: ConfigHub retained 85.3.3 as the base and 86.1.0 as the staging variant, required approval, published an exact release OCI for each, and delivered both through Argo CD. The destination check preserved the chart's monitoring and kube-system namespaces, supplied the two recorded Secrets, established ten CRDs, replaced two setup Jobs, and used server-side apply for the large CRDs. Read the ConfigHub promotion result. It covers this exact version pair and test target; rollback and automatic route selection have not run.
default: package applies 10 CRDs first
| Hook or setup step | Who handles it? | Argo CD mapping | Flux mapping | Change for this variant |
|---|
crd-install (preflight-or-presync-crd-apply)
The package applies the locked CRDs before the chart objects that use them. | Handled - the generated package script applies the CRDs first | PreSync · sync-wave -2 · ServerSideApply | HelmRelease .spec.install.crds=Create (or apply CRDs first) | resolved - the package carries and applies the 10 CRDs before the workload (observed live) |
hook-delete-policy (preserve-cleanup-policy)
The run removes both completed Jobs and their temporary RBAC objects. | Your delivery - an explicit, receipted step | none - your cluster handles it | none - your cluster handles it | - |
hook-phase (postsync-check-or-observation)
The package runs the chart's webhook patch Job after the webhook objects exist. | Your delivery - a post-apply check (receipted) | PostSync | post-apply Job / follow-on Kustomization | - |
hook-phase (preflight-or-presync)
The package runs the chart's certificate creation Job before applying the admission webhooks. | Your delivery - a preflight step before apply (receipted) | PreSync · sync-wave -1 | apply before the release (Kustomization dependsOn) | - |
hook-phase (upgrade-action-with-receipt)
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. | Your delivery - a GitOps PreSync/PostSync or cub action (receipted) | PreSync | apply before the release (Kustomization dependsOn) | - |
hook-weight-ordering (preserve-ordering)
The direct runner applies CRDs, creates the certificate, applies the workload, and patches the webhooks in that order. | Your delivery - an explicit, receipted step | no extra hook - keep CRDs before dependent objects | no extra hook - make sure CRDs are applied before workloads | - |
target-facts (target-facts-or-preflight)
The certificate Job creates the required admission Secret with ca, cert, and key. | Handled - the recorded package script creates or checks this prerequisite | none - supply the inputs before sync | none - supply the inputs before sync | - |
webhook-readiness (webhook-readiness-observation)
The run checks three CA bundles, the operator endpoint, a server dry-run, and six workloads. | Your delivery - an explicit, receipted step | wait for the certificate handoff, then observe webhook and workload health after sync | wait for the certificate handoff, then run post-apply webhook and workload health checks | - |
Evidence: data/hook-lifecycle/receipts/prometheus-community-kube-prometheus-stack/default/latest.yaml
runs/kps-lifecycle-route-proof/receipt.yaml
packages/prometheus-community/kube-prometheus-stack/85.3.3/prerequisites/kube-prometheus-stack-lifecycle/generation-receipt.yaml
recipes/prometheus-community/kube-prometheus-stack/85.3.3/revisions/default/r001/rendered/release-objects.yaml
runs/kps-default-package-upgrade-proof/receipt.yaml
no-crds: package applies 10 CRDs first
| Hook or setup step | Who handles it? | Argo CD mapping | Flux mapping | Change for this variant |
|---|
crd-install (preflight-or-presync-crd-apply)
The no-crds render omits CRDs, so the package applies the locked CRDs before the workload. | Handled - the generated package script applies the CRDs first | PreSync · sync-wave -2 · ServerSideApply | HelmRelease .spec.install.crds=Create (or apply CRDs first) | resolved - the package carries and applies the 10 CRDs before the workload (observed live) |
hook-delete-policy (preserve-cleanup-policy)
The run removes both completed Jobs and their temporary RBAC objects. | Your delivery - an explicit, receipted step | none - your cluster handles it | none - your cluster handles it | - |
hook-phase (postsync-check-or-observation)
The package runs the chart's webhook patch Job after the webhook objects exist. | Your delivery - a post-apply check (receipted) | PostSync | post-apply Job / follow-on Kustomization | - |
hook-phase (preflight-or-presync)
The package runs the chart's certificate creation Job before applying the admission webhooks. | Your delivery - a preflight step before apply (receipted) | PreSync · sync-wave -1 | apply before the release (Kustomization dependsOn) | - |
hook-phase (upgrade-action-with-receipt)
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. | Your delivery - a GitOps PreSync/PostSync or cub action (receipted) | PreSync | apply before the release (Kustomization dependsOn) | - |
hook-weight-ordering (preserve-ordering)
The direct runner applies CRDs, creates the certificate, applies the workload, and patches the webhooks in that order. | Your delivery - an explicit, receipted step | no extra hook - keep CRDs before dependent objects | no extra hook - make sure CRDs are applied before workloads | - |
target-facts (target-facts-or-preflight)
The certificate Job creates the required admission Secret with ca, cert, and key. | Handled - the recorded package script creates or checks this prerequisite | none - supply the inputs before sync | none - supply the inputs before sync | - |
webhook-readiness (webhook-readiness-observation)
The run checks three CA bundles, the operator endpoint, a server dry-run, and six workloads. | Your delivery - an explicit, receipted step | wait for the certificate handoff, then observe webhook and workload health after sync | wait for the certificate handoff, then run post-apply webhook and workload health checks | - |
Evidence: data/hook-lifecycle/receipts/prometheus-community-kube-prometheus-stack/no-crds/latest.yaml
runs/kps-lifecycle-route-proof/no-crds-receipt.yaml
packages/prometheus-community/kube-prometheus-stack/85.3.3/prerequisites/kube-prometheus-stack-lifecycle/generation-receipt.yaml
recipes/prometheus-community/kube-prometheus-stack/85.3.3/revisions/no-crds/r001/rendered/release-objects.yaml
runs/kps-gitops-lifecycle-proof/receipt.yaml
Before Production
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 review status | Ready for a target-specific production review |
| Target-scoped support decision | supported |
| Supported base | default |
| Target scope | vanilla kind (historical receipt); namespace=monitoring; delivery=confighub-oci; controller=argo |
| Accepted limits | CRD lifecycle and upgrade policy; cluster RBAC review; optional input sources and scan policy; ownership of generated values; warning review and apply-gate policy; cluster requirement checks before deployment; webhook readiness and failure policy |
| Open policy decisions | None recorded for this policy checklist |
| Next action | Keep the target-scoped evidence fresh before using this supported scope as a production-support example. |
Source And Evidence Files