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 one claim yourself
Choose the result you want to check, then run the matching command. These commands test this project's published results; they do not install your application.
A claim is checked only when the named command or receipt covers it. Everything else is not checked, even when a nearby test passed. First decide which answer you need. What you have, what it will produce, whether the destination can accept it, and whether it actually worked each need different inputs. Passing one check does not mean the next one passes.
| Question | Minimum input | Deployment needed? |
|---|---|---|
| What do I have? | The source, package, snapshot, or files to inspect. | No |
| What will it produce? | Source inputs plus its native tool, or literal objects where this step is a no-op. | No |
| Can this destination accept it? | The exact candidate plus current destination facts. | No |
| Did it work? | The exact delivered revision plus the live evidence required by the claim. | Yes |
Then use the smallest check that answers it. Some checks read evidence already committed to the repository. Others create clusters and produce a new live result. The table tells you which kind you are about to run.
| Question | Command or page | Needs cluster? | What it proves |
|---|---|---|---|
| What known configuration risks appear in these rendered objects? | cub plugin install confighub/homebrew-tap@cub-scan-v0.7.3 --name scancub check --format json --output cub-check.json ./rendered | No | A local advisory result with stable finding IDs and the pinned pattern bundle. It is not a cluster or runtime test. |
| Is this cub-scout receipt intact? | cub-scout receipt validate <receipt.json> | No | The receipt's fingerprint and structure validate locally. |
Product commands
cub, helm, kubectl, Argo, and Flux render, install, deliver, or manage configuration.
Project checks
The npm run ... commands that check this repository's generated files, receipts, and live lanes live in Verification, not on this page. npm run verify runs the whole chain.
Saved or fresh evidence
Saved evidence is already in the repository. Fresh evidence comes from a new run that may create kind clusters, use ConfigHub, publish OCI artifacts, and write receipts. Run live checks one at a time.
Open detailed instructions
| Topic | Use it for |
|---|---|
| Verification docs | The canonical docs landing page for proof commands and render-record-route. |
| Verify It Yourself | The practical command list for offline checks, rendered installs, parity receipts, and cub-scout receipts. |
| Verification Lanes | What each type of test proves and what it does not prove. |
| Choosing Commands | When to use product commands versus repo verifiers. |
| Expected Results And Clusters | Which steps need a cluster and what output to expect. |
| Outcomes And Tests | Which repo promises map to which test commands and CSVs. |
| Live Parity | How to read live Helm-vs-ConfigHub parity status. |
| Chain Of Proof | Which boundary is proven by render, ConfigHub, delivery, and live observations. |
| What We Refuse To Claim | The refusal boundaries that keep proof language honest. |
| Two-Cluster Harness | The stricter Helm-vs-cub kind harness. |
| NPM Script Catalog | The full script catalog for maintainers. |
4. 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 route, 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.
5. 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
6. 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 |
7. 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 routed; 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. |