Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this offering page.
The Problem We Are Solving
Helm users can usually install something. The harder problem changes by audience: a new user cannot see what will land until after the install; an app team ends up with values-file sprawl and forks; a platform reviewer cannot prove blast radius, approvals, delivery, and live convergence at fleet scale.
ConfigHub's answer is staged visibility: render first, turn common install shapes into named base variants, keep derived variants explicit, and attach scans, gates, receipts, GitOps handoff, and observations to the object set.
The catalog keeps the supported path close to the chart author's golden path, but makes each stage visible. That matters when humans or AI agents make changes: the recipe, variant, rendered objects, scans, gates, and live receipts show whether the change stayed on the path or created a new install shape that needs review.
This is the Helm-facing slice of Generative GitOps: render once, hold the result as data, show what was checked, and keep GitOps delivery. The current catalog proves the import and staged lifecycle path; full field authority, fleet propagation, and authorized live-to-desired reconciliation are not fully proven yet. Read the fit and limits.
Render parity is necessary, but it is only the starting point. It proves the cub installer path preserved Helm's intended object set for recorded inputs. The harder value is making target facts and lifecycle prerequisites explicit: staged CRDs, admission certificates, provider credentials, controller-owned fields, hook routes, and live observation boundaries.
kube-prometheus-stack is the main example. Its no-CRDs base is not just a smaller YAML bundle; it is a contract that compatible CRDs and admission certificate material must already exist or be staged before config-only delivery. The catalog records that contract instead of treating a green render as a complete install.
| Current limit | Current status |
|---|---|
| Field provenance | Blast-radius prediction is scored by a generated accuracy harness: 13 measured cases, 13 passing, 0 failing, and 0 unmeasured value-source rows. The claim remains per measured case; not every rendered field in every chart has provenance. |
| Change authority | ConfigHub records and gates operations; full per-field authority for every user or agent is not yet proven. |
| Live-to-desired flow | Live observations are recorded; authorized live fixes flowing back into desired state are future product work. |
| Hook execution | Hooks are inventoried, routed, observed, refused, or marked per-target; universal hook execution is not claimed. |
| Fleet propagation | Derived variants, blast-radius cases, and promotion examples exist; complete fleet propagation is still being built. |
| Signatures as trust | The claims register enforces reviewer guardrails: no evidence means no current claim, partial stays partial, and refused claims stay visible. Signatures still prove integrity and transport only within a named signer, authority, and verification context. |
New Helm user
Wants to see what a chart will do before it creates Secrets, CRDs, RBAC, storage, or workloads in a cluster.
App team or GitOps operator
Wants dev, staging, prod, region, and customer differences without values sprawl, fork pressure, or copy-paste promotion.
Platform SRE
Wants blast-radius preview, prerequisites, receipts, and observation freshness before fleet changes ship.
Security reviewer
Wants scans and gates on exact rendered objects before deployment.
Catalog maintainer
Wants to know which charts are ready, watch, blocked, or need better variants.
What The Offering Is
A public catalog of maintained Helm-derived packages, plus a free ConfigHub account that lets you edit the rendered config and keep your edits through upgrades. The paid tier covers private charts, teams, policies, fleet operations, and production support.
The free lane lets you browse, inspect, template, and install catalog chart bases without a ConfigHub account. With a free account you can also edit any rendered field and keep it through upgrades, plus basic variants, diffs, and scans. The paid lane covers private charts, custom catalogs, teams, policies, approvals, fleet operations, GitOps and OCI at scale, patch and upgrade services, and production support.
| What you get | No account | Free account | Paid |
|---|---|---|---|
| Browse, inspect, and template catalog charts | Yes | Yes | Yes |
| Install a chart base and read the exact objects | Yes | Yes | Yes |
| Edit a rendered field and keep it through upgrades | No | Yes | Yes |
| Environment variants, diffs, and scans | No | Basic | Full |
| Private charts and custom catalogs | No | No | Yes |
| Teams, policies, and approvals | No | No | Yes |
| Fleet operations, GitOps and OCI at scale | No | No | Yes |
| Patch and upgrade services, production support | No | No | Yes |
| Layer | What it gives a Helm user |
|---|---|
| Render parity | Compare regular Helm rendering with the cub installer package output. |
| Exact object review | Review the Kubernetes objects, not just the values file that may produce them. |
| Target prerequisites | Record required CRDs, Secrets, StorageClasses, cloud credentials, or controller assumptions as explicit facts. |
| Lifecycle evidence | Stage or route hook-like behavior and observe the target where a live claim is made. |
| Scans and gates | Bind policy findings and decisions to the rendered object set. |
| Variants | Use base variants for Helm render choices and derived ConfigHub variants for approved post-render changes. |
| Live evidence | Record what a local cluster, GitOps controller, or observer actually saw. |
| Watchlists | Keep target capability and lifecycle gaps visible instead of silently turning them green. |
Start At Your Stage
Each stage asks for more trust and gives more value. Direct Helm paths answer immediate render or upload questions; the public catalog adds maintained bases and proof; ConfigHub-managed workflows add private inputs, teams, approvals, variants, and operations.
| Path | Use it when | Command or surface | Boundary |
|---|---|---|---|
| Quick render | See what any chart renders without ConfigHub state. | helm template | Free/direct |
| One-shot upload | Load rendered files or a literal configuration OCI into ConfigHub Units. | cub variant upload <files-or-oci-ref> | ConfigHub account |
| Catalog package | Use a maintained base with render parity, receipts, scans, and proof. | cub installer setup --pull oci://... --base <base> | No ConfigHub account or registry login for public package pulls |
| Reviewed ConfigHub base | Upload a reviewed rendered base before variants or approvals. | cub installer upload | ConfigHub account |
| Derived operations | Create environment, region, customer, or target variants after upload. | cub variant create | ConfigHub-managed |
Open the full route picker for tutorial links, free/public boundaries, and ConfigHub-managed operations.
Why This Helps
Change safely
When a person or AI agent changes a chart input, base variant, or post-render ConfigHub variant, the pipeline can compare the exact object set, scan it, and show the receipt trail before the change is promoted.
Stay on the supported path
Many Helm failures come from accidentally driving a chart away from the path its authors expected. The catalog makes supported bases explicit, records where a custom choice belongs, and flags target or lifecycle gaps before they become production surprises. It keeps the user on the right path and makes departures visible.
For a day-2 example, read how an opaque Helm upgrade becomes staged, reviewed, rehearsed, gated, and observed.
Try It Without A Big Commitment
The first path is closer to helm install redis than to a platform migration. Start with a catalog package and local verification. A ConfigHub account is free: use it to edit the rendered config and keep your edits through upgrades. The paid tier is for private inputs, teams, and production workflows.
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/bitnami-redis:25.5.3 \ --base default \ --work-dir .tmp/redis \ --non-interactive \ --namespace redis
Low-friction public use
- Browse public catalog: See chart versions, base variants, proof status, pain reports, and known gaps.
- Inspect and template: Use helm template or a catalog package's rendered-object views before committing to ConfigHub state.
- Use catalog packages: Run cub installer setup --pull oci://... --base <base> for supported catalog bases.
- Pull package artifacts: Use package or OCI artifacts where available without uploading private repo or production state.
- Verify locally: Check available signatures, digests, rendered objects, receipts, or chart-specific verifiers on your own machine.
- Inspect proof: Read receipts, rendered objects, Helm pain reports, and current status without trusting a screenshot.
ConfigHub-managed use
- Private and custom catalogs: Import wrapper charts, private values, customer overlays, private OCI sources, and team-specific catalogs.
- Managed variants and teams: Create environment, region, customer, and target variants with teams, approvals, policies, links, target facts, and receipts.
- Fleet operations: Bulk scan, patch, approve, promote, observe, and audit across many spaces or clusters.
- GitOps and OCI operations: Manage delivery handoffs, controller credentials, artifact access, observations, rollback evidence, and audit history.
- Full-stack support: Target-scoped production decisions, patch services, upgrade services, old-version support, SLAs, policies, and approvals.
What Is Proven Today
The repo is explicit about what is proven and what is still a watch or blocked item. A green render check does not become a production support claim.
Top-100 readiness is also separated by usefulness:
| Bucket | Charts | Meaning |
|---|---|---|
| ready-to-try | 20 | Catalog-supported with a reviewed first base and live evidence. |
| works-with-target-prerequisites | 15 | Works once the target provides the named prerequisite. |
| works-with-operator-review | 23 | Render proof exists, but an operator needs to review the named concern first. |
| needs-better-base-variant | 33 | The useful install shape has not been built and reviewed yet. |
| not-ready-yet | 9 | A limitation needs a support, disclose, defer, or block decision. |
Open the plain-English top-100 status or open the generated user-readiness table.
Why This Should Be Trusted
The catalog is designed to expose hard cases, not hide them. The latest strict cub-scout witness work found Kubernetes 1.30 CRD capability issues in cert-manager and External Secrets, plus a Grafana RBAC server-normalization watch item: workloads converged, but strict rendered-object/live parity stayed blocked until the target behavior is modeled or accepted.
That is the point of the model. It tells the user what is true, what is watch, what is blocked, and what decision is needed next.
| Signal | Current meaning |
|---|---|
| PASS | The stated lane met its contract. |
| WATCH | The main path worked, but extra live state or a runtime condition needs review. |
| BLOCK | The lane found a missing prerequisite, runtime failure, or target capability conflict. |
| Missing | Backlog, not a failed chart. |
Send A Problem Chart
If a public Helm chart breaks the model, or if the catalog output for a supported chart does not match the Helm behavior you expect, send the chart and the values that expose the problem.
The expected response is a public fixture and a receipt: pass, watch, blocked, or refused with a named reason. Private charts, private values, production remediation, and fleet rollout work belong in managed ConfigHub workflows.