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.
1. Read the current counts
Each count answers a separate question. Production use still needs a target-specific decision and current evidence.
2. See what each test covers
| Test | Question | Evidence | Limit |
|---|---|---|---|
| Render comparison | Did cub installer preserve the Helm object set? | Helm render receipt and installer comparison. | Applies only to the recorded chart, version, configuration, values, and Kubernetes capabilities. |
| ConfigHub storage and checks | Were the rendered objects uploaded and checked as Units? | ConfigHub, scan, and safe-operation receipts. | Does not prove GitOps delivery or workload health. |
| Local Kubernetes run | Did the configuration apply and become ready on Kubernetes? | Observation and workload receipts, with PVC, CRD, or Secret checks where needed. | Usually uses local kind; production needs its own target scope. |
| Argo CD and OCI run | Did Argo CD pull and reconcile the ConfigHub release OCI? | Argo CD sync, health, and live observation receipt. | A green sync is not enough unless the runtime checks also pass. |
| Helm and ConfigHub live comparison | Did Helm and ConfigHub reach the same live result? | Live Helm-versus-ConfigHub comparison receipt. | Available for selected configurations; no receipt means not yet tested. |
| Two-cluster Helm and cub comparison | Did Helm on one new kind cluster match cub installer on another? | Two-cluster comparison receipt. | Does not prove ConfigHub or OCI unless a separate result records them. |
| Hooks and prerequisites | Were hooks, CRDs, webhooks, generated values, and target requirements handled? | Lifecycle, hook, target, and serious-chart receipts. | Some configurations still need a user decision, a target-specific step, or more work. |
Verification Lanes explains test meanings. Chain Of Proof separates repository, ConfigHub, GitOps, and live evidence.
3. Check the harder charts
Hard charts are where mistakes hurt. Examples include kube-prometheus-stack and cert-manager, and any chart with hooks, CRDs, or webhooks. Generated Secrets, storage, and target requirements add their own risks.
This is the expert and SRE problem. Before a fleet change ships, someone must know what it touches and what the cluster must provide. They also need the check, delivery, and live results.
For these charts, a green render is not enough. The page must name the prerequisites, lifecycle plan, target observation, and production review status.
kube-prometheus-stack
Upgrade crash example
How a high-risk Helm upgrade becomes staged, gated, and observed.
cert-manager and ESO
Lifecycle observations for CRDs, webhooks, and controller-populated fields.
Argo Workflows
Hook-delivered CRDs routed through the lifecycle boundary.
Argo Rollouts
Default and no-crds bases now have live Helm-vs-ConfigHub parity receipts.
Hooks
Top-100 hook results record each hook's disposition; see what the five disposition words mean.
4. Review security before release
The public Catalog reports what a chart does rather than certifying it as secure. It gives you the exact Kubernetes objects, their source, and the checks recorded against them. Your team makes the security decision and keeps it with the same object set.
Helm values hide security choices that only show up once the chart is rendered. Generated passwords, broad RBAC and privileged containers are the common ones. Image tags, CRDs, webhooks and controller behaviour hide there too. Review those choices in the rendered objects. ConfigHub can keep the recorded decision with the same object set.
| Area | What to record or check |
|---|---|
| Rendered objects | Review the actual Kubernetes objects before delivery, not only values files. |
| Secrets | Separate, reference, or require external Secrets where appropriate. Do not hide placeholder credentials. |
| Scans and gates | Run policy and security checks against explicit desired state before delivery. |
| OCI delivery | Publish a reviewed bundle so the controller pulls the same bytes that were checked. |
| Receipts | Record what was rendered, delivered, observed, accepted, blocked, or refused. |
Some evidence is partial by design. A digest proves integrity inside a known trust chain, and says nothing outside one. A scan finding still needs a human decision. A clean render tells you the objects are well formed, while cloud identity, storage and runtime policy at the target remain unchecked.
Security guide
Known caveats
Claims register
5. Find tests designed to expose failure
You still need to test on your own cluster before production. See how the catalog is built for the rules contributors follow when writing these tests.
Use the problem chart issue template to report a public chart, a values file, or a catalog entry that does not match Helm.
| Test or record | What it answers | Open |
|---|---|---|
| Claims register | Every public claim is backed, partial, planned, or refused. | Open Claims register |
| Blast-radius accuracy | Predicted affected objects are scored against actual rerender diffs, including published failures. | Open Blast-radius accuracy |
| Synthetic torture suite | Breaker charts land in named pass, refusal, or route outcomes; silent outcomes fail. | Open Synthetic torture suite |
| Environment checks | The project checks whether timezone or locale changes the rendered objects in the tested examples. | Open Environment checks |
| Hook handling | Charts with hooks show whether the hook was observed, given an explicit route, left to the target, or still needs chart-specific work. | Open Hook handling |
| Master matrix | Every chart/version/base row carries test status, source links, production scope, and next action. | Open Master matrix |
6. See what this project does not claim
| Refusal | Why it matters |
|---|---|
| No blanket chart support | Every claim names chart, version, base, test, and target profile. |
| No whole-values-space proof | The catalog proves named bases. Custom values must be rendered, checked, and recorded with receipts. |
| No universal hook execution | Hooks are inventoried and assigned a step; execution is claimed only with live evidence. |
| No production claim from render parity | Production support requires target-scoped decisions and fresh receipts. |
| No signature-as-safety shortcut | Signatures prove origin/integrity. Scans, policies, and live evidence carry safety claims. |
7. Check why you can trust an entry
Every published entry is an image of the exact objects, with a receipt of what was checked. Three words say how far each one is proven.
- Verified. The render matches Helm's own output for the recorded inputs, so a base variant is proven rather than asserted.
- Certified. A whole composition passes its checks before anything renders. The checks find conflicts between parts and declared needs that no part meets, and they do not show that the platform runs. See how a stack is certified.
- Signed. A signature records who published the image.
cub config verifyconfirms the image is exactly what its receipt says and refuses one with none. The receipt says what was checked, not that the configuration will run on your cluster.
Verify a signed image yourself, or see what this catalog does not claim.
8. Stack receipts and boundaries
The eks-inference sandbox receipt · The composition verdict · The certified-bundle receipts · The plugin repository and its ten-minute walkthrough
The four nouns are proposed verbs packaged as a prototype; ConfigHub's own verbs underneath are released. The composition verdict runs here as the plugin's stack check and in the repository as a regression gate. As a gate inside the ConfigHub product it remains proposed, and this page does not claim otherwise.