Production Support Decisions · Config Workshop

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.

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

UNOFFICIAL/EXPERIMENTAL

Use this page when a chart is already production-review-ready and the next question is whether ConfigHub should call one chart/base/target combination production-supported.

Production support is not created by a green render check. It is a scoped operating decision.

chart + version
base variant
target scope
delivery path
image and scan decision
lifecycle policy
fresh live evidence
operator-owned boundaries

The current top-20 catalog has pre-review disposition evidence for every chart. All twenty charts are production-review-ready. Vault dev-mode remains rejected as a production support boundary because it is a local/demo base. Disposition evidence does not mean every chart is production-supported.

The Boundary

State	Meaning
`catalog-supported`	The chart is in the public catalog with maintained bases and local-test proof.
`production-review-ready`	The required pre-review disposition receipts exist. A support decision can now be made.
`production-supported`	A target-scoped support decision has been recorded and backed by fresh evidence.

The support decision names the exact promise. For example, it might support bitnami/nginx@24.0.2 with the http-clusterip base on a vanilla Kubernetes cluster through ConfigHub OCI and Argo, with image digests resolved and a freshness rule for live evidence.

That decision would not automatically support every NGINX base, every ingress mode, every cluster type, or every private overlay.

How To Work The Queue

Start with the target-scoped support decisions:

Use the older production-disposition outputs when you need the accepted pre-review receipts or the original decision contract:

Then work the target-scoped row by decision field:

Use work-items.csv when you want assignable rows. One chart can have several rows because image, scan, lifecycle, runtime, and fresh-evidence work can be owned and closed separately.

Decision field	What to do
`image_decision`	Pin images by digest or record the explicit exception for the supported scope.
`scan_decision`	Decide which findings are accepted, fixed, hardened, or outside the supported target scope.
`lifecycle_decision`	Decide which lifecycle behavior is supported, observed, excluded, or operator-owned.
`target_fact_decision`	State required CRDs, APIs, Secrets, storage, or other target prerequisites.
`live_evidence_decision`	Refresh target-scoped live evidence, or close the runtime/missing-lane/lifecycle decision first.

Minimum Decision

A useful support decision should record at least:

chart: bitnami/nginx
version: 24.0.2
supportedBase: http-clusterip
targetScope:
  clusterClass: vanilla-kubernetes
  namespace: nginx
  gitopsController: argo
deliveryPath: confighub-oci
imageDecision: digest-pinned
scanDecision: accepted-for-scope
lifecycleDecision: no-chart-hooks
requiredLiveEvidence:
  - live Helm-vs-ConfigHub parity for this base and target scope
  - ConfigHub OCI/Argo sync and workload observation
freshness:
  liveEvidenceTTL: 30d
supportBoundary:
  includes:
    - declared base variant
    - declared target scope
    - declared delivery path
  excludes:
    - private overlays
    - other base variants
    - unreviewed extension slots

That shape is an operating contract, not a new install mechanism. The actual implementation still uses cub installer, ConfigHub Units, cub variant create where needed, scans, changesets, approvals, OCI/GitOps, and live observation.

Current Decisions

The current queue has support decision artifacts for all top-20 catalog charts:

data/production-support-decisions/<chart>/support-decision.yaml

The current generated summary is:

decision artifacts: 20
supported decisions: 17
draft decisions: 0
rejected decisions: 1
superseded decisions: 2
open work items: 0

Each decision names:

base variant
target scope
delivery path
accepted evidence and risk decisions
what remains operator-owned or out of scope
next action

The generated summary is:

data/production-support-decisions/summary.md

The verifier checks that every row in the production support queue has its named decision artifact. That keeps the support surface actionable instead of being a loose spreadsheet.

Current Decision Groups

Group	Charts	What it means
`supported`	17	The named chart/base/target/delivery scope has fresh evidence and an explicit operating boundary.
`superseded`	2	The proof remains useful, but the upstream chart source is deprecated and should not be promoted as production-supported.
`rejected`	1	The base remains parity evidence, but it is not a good production support boundary.
`draft`	0	No current top-20 support decisions are draft.

The next production work is specific:

keep evidence fresh for the 17 supported scopes;
choose maintained successor sources for Grafana and Tempo;
create a production Vault base with init/unseal, storage, TLS, backup/restore, and an operator runbook;
create an ingress-nginx support scope that matches the target environment, such as real LoadBalancer behavior or a deliberately admission-disabled topology.

What Users Should Expect

A production-supported row should let a user answer:

Which base should I use?
Which target is it supported on?
Which delivery path is covered?
Which findings or lifecycle behaviors were accepted?
What live evidence proves this exact scope?
What remains my responsibility?

If any of those answers are missing, the chart may still be useful, tested, and review-ready, but it should not be called production-supported.