Check your own chart and values, or compare rendered Kubernetes YAML. Keep the findings and the exact configuration they describe.
Start with my chart and values I have rendered YAML Plan token cost
Use this page for your own chart, values, new version, or unexpected result. Use the Catalog when we have already tested the exact chart and version.
The chart route builds instructions for your local AI assistant. Already have rendered YAML? Check it in this browser with no AI needed. Neither route deploys your configuration.
Flattened configuration means the fully rendered Kubernetes objects, with template choices already resolved. You can inspect and change that data before choosing a delivery path.
Checking private configuration? Keep the chart, values, and output on your machine. Do not upload private files; this page does not upload them for you. Keep secrets out of the form, AI prompt, and any public issue.
Keep the result locally, publish the reviewed objects as OCI, or retain the same result in ConfigHub when a team needs history and promotion.
Already accepted a result? Compare the exact current result with the candidate for the next stage. The promotion review shows what changed, what blocks the move, and which destination checks have not run.
Doing this regularly? Install the ConfigHub Workshop agent skill so your assistant follows the same version, evidence, lifecycle, and safety rules.
| Question | What happens here |
|---|---|
| What do I have? | The page inventories and compares the exact rendered objects you provide. A local assistant can also inspect the source, values, or package. |
| What will it produce? | Helm, AICR, Timoni, or another source tool runs on your machine. The browser checks its output; it does not run the source processor. |
| Can this destination accept it? | Not from browser files alone. Run a destination check with the exact candidate and current target facts. |
| Did it work? | Not before deployment. Record controller, resource, runtime, drift, and rollback results after the exact revision is delivered. |
Already comparing GPU nodes rather than a deployable configuration? Use AICR snapshot and diff. That read-only path needs cluster access but no recipe or bundle deployment.
Each command answers one question about your configuration. None of them says whether the workload runs on your cluster.
| Command | Catches | Does not catch | Needs |
|---|---|---|---|
cub config check | YAML or JSON that does not parse. Invalid container resource requests and limits. A workload whose selector does not match its pod labels. A schema violation, such as a wrong field type, an unknown field or a broken CEL rule. CRDs, Helm hooks, setup Jobs, webhooks that need a certificate, and images that are not pinned. | Admission policies, quotas and anything that depends on your cluster. | Nothing for the file checks. The schema step needs flux 2.9 or later with flux plugin install schema, and network access. |
cub config check --images | Images that do not exist or cannot be pulled anonymously. | Private images, which read as incomplete. | oras and network access. |
cub config values | Values that changed nothing in the render. | Whether a value that did change something is right. | helm. |
cub config diff | Every object and field that changed between two files. | Whether the change is safe. | Nothing. |
cub app check | The platform services a workload needs. | Whether a platform provides them. cub app match compares. | Nothing. |
cub stack check | Conflicts and missing needs between components, and schema violations. | Whether the components work together at runtime. | The schema step needs flux as above. |
The scan plugin's cub check adds best-practice and security findings, such as missing resource limits or a container that may run as root. In ConfigHub, the vet-schemas function blocks an apply that fails its schema. The schema step and the selector check arrived in the Workshop plugin's release 0.6.59.
Use a deterministic check when it can answer the question. AI is most useful for selecting evidence, explaining a diff, or proposing a bounded change; it should not spend tokens reproducing work that Helm, cub, or this browser can do exactly.
| Route | Rough input / output | Expected result, proof, and boundary |
|---|---|---|
| Rendered YAML in this browser, or local render/diff/check commands | 0 / 0 AI tokens | Expected: an inventory, exact diff, check result, and downloadable hashes. Proven: only the deterministic local checks that completed. Not proven: source rendering the browser did not run, delivery, controller convergence, or workload health. |
| One Catalog answer | 6k–15k / 0.5k–2k | Expected: one matching entry, Guide, and named receipt. Proven: only the claim that receipt covers. Not proven: behavior on your target. Resolve one id, then read one listing; do not feed the model all of configs.json or listings/index.json. |
| Understand or fix your chart, values, or objects | 10k–30k / 1k–4k | Expected: one rendered candidate, the smallest proposed fix, and an exact diff. Proven: the local render and checks that ran. Not proven: admission, delivery, health, upgrade, or rollback unless each has its own result. |
| Discover an existing app, app-of-apps, controller setup, or stack | 20k–80k+ / 2k–8k | Expected first: a read-only inventory and reversible handover plan for one root or leaf slice. Proven: the observed inventory. Not proven: a successful transfer of control, deployment, or live outcome. |
How to read the estimates. They are rough planning ranges for one focused turn, not quotas, provider bills, or guarantees. They include the likely Guide, one relevant record, task files, and useful command output; an agent host may add system instructions, tool transcripts, retries, and uncached context. The planning heuristic is about one token per four characters. At the current site size, llms.txt is about 4.5k tokens and the core SKILL.md is about 5.2k before references or task files. Use your provider's token meter for the actual count. To estimate money, multiply input and output tokens by that model's current per-million-token rates; caching and tool billing vary by provider.
llms.txt as a router, search an index for one matching row without adding the whole index to context, then read one Guide and one listing or receipt.An answer is not the end of the journey. Keep each boundary visible so a quick local success does not become an unsupported deployment claim.
| Checkpoint | What good looks like |
|---|---|
| 1. Awareness | See a concrete before-and-after example on the Workshop front door, not only a product category. |
| 2. Problem match | Choose the job you already have: understand, change, build, connect an existing controller, or repeat a proven result. |
| 3. Find | Open one matching Guide or use Check my config; do not make the reader assemble a path from unrelated pages. |
| 4. Understand | Read the inputs, expected result, what that result proves, and what remains untested before running anything. |
| 5. Start | Run the smallest local or read-only step first. Private files stay local, and every write or delivery step remains explicit. |
| 6. First value | Keep an exact diff, object hash, check result, or inventory that answers the original question. |
| 7. Delivery request | Choose deliberately whether to keep the result local, publish OCI, or save and release it with ConfigHub. No earlier step silently deploys. |
| 8. Verified live | Check the release, controller reconciliation, Kubernetes resources, and workload health separately; use the known limits when proof is missing. |
| 9. Expand or return | Pin the useful inputs and commands, repeat them in CI where appropriate, then take one next environment, app, or Guide rather than reopening the whole catalog. |
Choose one question. This form does not upload a values file or render Helm in your browser. It builds instructions for the Claude, Codex, or other AI assistant already running on your machine. The assistant runs Helm locally, records the inputs, and compares the exact objects.
ConfigHub is useful when a team needs to keep an accepted decision with the configuration, then approve and promote it. See the completed NGINX review carried through ConfigHub and staging; you can finish this local review without signing up.
This question has a walk-through for your own files:
Search the Catalog for this chart and version. Use a tested record when one exists; keep investigating locally when it does not.
Compare the candidate with an older version, an installed Helm release, local YAML, OCI, Git, or live Kubernetes output. Everything stays on your machine.
For an installed Helm release, add both fields below. The prompt will read Helm's status, values, manifest, hooks, history, and stored release record.
Paste this into the assistant you already use. It runs Helm and ordinary shell tools locally, writes the candidate and comparison objects to files, and returns a short WORKSHOP FINDING. This site does not receive the prompt or answer.
When the assistant finishes, return with candidate.yaml, the optional comparison file, and its final WORKSHOP FINDING block.
Use this after Helm, AICR, OCI, or another source tool has written Kubernetes YAML. The command checks the exact files on your machine. It does not upload them, contact ConfigHub, or apply them to a cluster.
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 plugin install confighub/homebrew-tap@cub-scan-v0.7.3 --name scan
cub check --format json --output cub-check.json ./renderedcub-check.json records stable finding IDs and the pinned pattern bundle used for the check. Keep it beside the rendered files and their digest. The result is advisory: cluster admission, hooks, CRDs, workload health, upgrade behavior, and rollback still need their own checks.
See the same three jobs through the website and released cub commands. The Helm and plain-YAML examples use the same WorkshopResult record and carry one canonical object-set hash into the ConfigHub upload.
In the worked NGINX case, the proposed values produced six local findings and an unwanted public LoadBalancer. The reviewed result fixes six problems and keeps one emptyDir finding visible under a narrow, dated exception for development and staging only.
The same record then follows the accepted objects into ConfigHub, through a development-to-staging promotion, and into two Argo CD test deployments. Each step says what it proves and what it does not prove.
For a lifecycle-heavy upgrade, read the Kube Prometheus Stack 85.3.3 to 86.1.0 destination result. It checks namespaces, CRDs, server-side apply, prerequisites, approval, release OCI, and Argo CD separately.
Add the exact rendered candidate. Add a second object set when you want to compare it with defaults, an older version, production, OCI, Git, or exported live objects.
Helm, AICR, and Timoni must produce their Kubernetes objects locally first. This browser checks those objects; it does not run the source tool.
The browser records object identities and hashes, reports added, removed, and changed objects, and checks a short list of common manifest risks. This is a first check, not a Helm render, Kubernetes schema check, admission test, hook run, or live health test.
The checks on this page run in your browser. This page does not send your files to an AI service. You may use your own Claude, Codex, or other AI assistant to investigate findings or propose fixes. Check its proposed commands, objects, and evidence before accepting them.
Do not add credentials or Secret values. Keep private source names and paths local. The optional public Catalog proposal is only for material you are allowed to publish.
If the candidate starts from a Catalog configuration, add its BaseVariantRecord. It connects the source, rendered objects, OCI package, prerequisites, lifecycle steps, policy, and evidence status.
cub check (optional)Run the shared checks on the same candidate files, then add cub-check.json. The page accepts it only when its object count and object-set hash match these exact objects. The result remains local advisory evidence; ConfigHub validation is a separate managed check.
You can add a local check result for this candidate.
This browser check does not search the Catalog automatically. Find a matching chart record, then add its source and intent record above when you want the result to include known prerequisites and lifecycle work. See what charts hide for the phases, dispositions, and CRD menu behind this list.
workshop-result.json contains the exact candidate YAML, optional comparison and Catalog record, the browser review, any matching cub check result, and every file hash. Keep it locally or give it to the AI and CI tools you already use.
Only completed checks count as evidence. Everything else is not checked and cannot support a safety claim.
Complete result hash:
Create a pull-request report from this result. The same local command works for Helm, OCI, AICR, Timoni, and literal YAML after each source has produced exact Kubernetes objects.
See how to keep this in ConfigHub Open the ConfigHub tutorial See what this check does not prove
Read the WorkshopResult schema.
The separate review record links the question, source identity, object hashes, comparison, findings, and checks that did not run. Keep it beside the reviewed YAML.
A saved object set can restore the configuration that was delivered. It cannot undo database migrations, cloud resources, or other external effects. Live comparison is a separate check after delivery. Read the upgrade and rollback walkthrough before claiming that a rollback will restore the exact release.
Read the ConfigurationReview schema.
ConfigHub stores the exact Kubernetes objects you approved. It keeps the review record and any matching local check result beside them without adding those evidence files to a deployment release. Local findings remain advisory; ConfigHub records its own validation against the stored revision.
Candidate file hash:
Accepted object-set hash:
The file hash identifies the exact bytes you reviewed. The object-set hash identifies the Kubernetes objects across file names and document order. The upload records both identities and the review hash on the saved configuration.
If the candidate contains a Kubernetes Secret, stage that Secret separately. cub variant upload deliberately does not upload rendered Secret data.
If Claude, Codex, or another assistant is already running on your machine, download the candidate and review record above. Then copy these instructions into that assistant. It will inspect the same files, ask before writing to ConfigHub, run the generated commands, and read the stored objects back.
See how ConfigHub keeps this result.
Use this only for a public source when the Catalog is missing the case or its answer is wrong. GitHub opens with a short chart, version, and question link. Paste the copied finding or review record, remove private data, and include reproduction commands.
A maintainer must reproduce and classify the case before it becomes a Catalog entry. Rendering alone does not make it known-good.
These four came up most often in a review of forty recent public Helm discussions.
| Question | Answer | Start |
|---|---|---|
| What will this install, and what must already exist? | List the rendered objects and every required namespace, Secret, CRD, API, storage class, cloud service, hook, and setup job. | Start this check → · 8 of 40 discussions |
| How is this candidate different from production? | Compare the two exact object sets and their source records. Keep desired-configuration differences separate from live-cluster drift. | Start this check → · 6 of 40 discussions |
| I set a value. Why did the rendered object not change? | If Helm ignored a setting, check first for a misspelled or wrong values path. Render with and without the value, identify the correct path, or report that the chart does not expose the field. | Start this check → · Check every key in your own chart → · 5 of 40 discussions |
| The chart does not expose the field I need. Must I fork it? | Show the rendered object and missing field. Keep the chart unchanged when a reviewed post-render edit is enough, then check that edit for overlap on upgrade. | Start this check → · 5 of 40 discussions |
We reviewed 40 recent public Helm discussions before starting outreach. The counts describe that small research sample; they are not customer or site usage totals.
Choose the question closest to the decision you need to make. Each link selects it in the form above.
| Recent discussions | Question | What the answer should contain |
|---|---|---|
| 8 | What will this install, and what must already exist? | List the rendered objects and every required namespace, Secret, CRD, API, storage class, cloud service, hook, and setup job. |
| 6 | How is this candidate different from production? | Compare the two exact object sets and their source records. Keep desired-configuration differences separate from live-cluster drift. |
| 5 | I set a value. Why did the rendered object not change? · Check every key in your own chart → | If Helm ignored a setting, check first for a misspelled or wrong values path. Render with and without the value, identify the correct path, or report that the chart does not expose the field. |
| 5 | The chart does not expose the field I need. Must I fork it? | Show the rendered object and missing field. Keep the chart unchanged when a reviewed post-render edit is enough, then check that edit for overlap on upgrade. |
| 4 | Can I upgrade this chart without breaking production? | Render both versions with the same release context. Compare objects, hooks, CRDs, immutable fields, storage, Secrets, and the current Helm release record when available. |
| 4 | How should Argo CD or Flux handle this chart's hooks and CRDs? · Check a release before Argo CD or Flux takes it over → | List each hook, CRD, and setup job in order. State who runs it, what must already exist, and which controller path has been tested. |
| 3 | Where does this vulnerable image run, and how can I update it safely? | Search supplied estate or ConfigHub records, show every affected environment and cluster, test the candidate, and promote it through a limited rollout wave. |
| 2 | Can I roll back to exactly what ran before? | Find a retained rendered revision or OCI digest and restore those exact objects. Keep database migrations and other external effects outside the configuration claim. |
| 2 | Do these version and digest records identify the same bytes? | Record the available chart and package digests and compare them with retained, dated evidence. |
| 1 | AI wrote these values. What did they actually change? · Review an AI rewrite and keep your fixes → | Render the candidate and compare it with the chart defaults, the Catalog, and optionally the current deployment. Show exact changes and check credentials, permissions, images, storage, hooks, and CRDs. |
What happens to a public question explains how a question sent in public becomes a checked answer, a named refusal, or a documented limit.
Use this FAQ when one question blocks your next step. It covers Helm compatibility, ConfigHub, hooks, CRDs, values, upgrades, free use, and current limits. Each answer says what works, what remains limited, and where to check the evidence.
No. You keep your Helm charts and values. The Catalog adds tested starting configurations and shows their exact Kubernetes objects. ConfigHub stores the reviewed objects, the approvals, and the release history.
No. Keep your charts, values, templates, and current delivery tools. This project helps you inspect and manage the objects they produce.
cub helm starts with any chart and values. It can render locally or record the rendered base and Helm source in ConfigHub. cub installer starts with a maintained Catalog package containing named configurations and requirements. Both are optional preparation tools.
No. A chart can expose too many combinations to test as one claim. The Catalog covers common operating choices with chart-specific base variants. Examples include no-CRDs, existing Secret, server-only, HA, and internal service.
Yes. That is deliberate because Helm charts have different operating choices. AI can help update the configurations across versions, but tests decide what the Catalog accepts.
A base variant is one supported way to render a chart version, with its Helm values, rendered YAML, and extra install work all recorded together.
No. Redis teaches the basic path. The kube-prometheus-stack example covers CRDs, webhooks, RBAC, generated values, cluster requirements, upgrades, and live checks.
The counts come from committed test results. Use them for orientation, then open the matrix for the exact chart, version, and configuration.
Choose a chart configuration and record its Helm values and render settings. Inspect the Kubernetes YAML and handle its required setup. ConfigHub can then store, change, approve, and release the reviewed objects. Delivery and live checks remain separate recorded steps.
ConfigHub publishes the reviewed Units in one Space as a release OCI. Argo CD or Flux pulls it without rendering Helm again. A separate direct local test checks that the same artifact is portable. A hook fixture proves the mechanism, and an NGINX receipt proves one catalog base at one digest. Other bases need their own receipts. cub cluster up installs the Argo CD pull credential. The Flux test copies it into flux-system without printing it.
ConfigHub compares the candidate with the Kubernetes objects you already reviewed. It publishes the approved result as OCI. Every Unit keeps its revision history. The Redis live test restored the exact pre-upgrade revisions and published a rollback OCI. It then tested both clusters again. This restores configuration, not database data. Irreversible migrations still need a chart-specific recovery plan.
A Unit is one versioned desired-state record. A Space holds related Units. A Target defines where ConfigHub delivers them. An OCI Target publishes the Space as a bundle.
You keep your controller. Point it at the OCI bundle that ConfigHub publishes from reviewed Units. The controller no longer rerenders Helm values from Git. Hooks become steps in a recorded plan, with named execution.
Ask AI to propose a new base, derived variant, policy change, or object patch. ConfigHub can show the diff and require tests or approval. Do not let AI rewrite live state or bypass the recorded change path.
Each chart page names the hidden work and gives it a step: a lifecycle phase, who runs it, and one of five dispositions. Every step stays automatic: false until ConfigHub can select and run it for you, so a green render never proves a hook, a CRD, or a target fact is handled.
Do not hide them inside ConfigHub by accident. The catalog separates generated Secrets, existing-Secret references, target facts, and runtime Secret lifecycle where the chart requires that distinction.
Security end to end · Secret lifecycle data · Target prerequisites
Yes, within recorded bounds. The fleet record predicts which objects a base change touches in each environment. Environments shielded by their own override are marked. A live receipt shows one reviewed edit fanned out to three environments, each behind its own approval. Beyond the recorded fleets, no claim is made.
Not by itself. Sync means the controller accepted the desired state. Workload convergence, target prerequisites, controller-owned fields, and semantic parity need separate evidence.
The model breaks the upgrade into visible steps: old render, new render, object diff, and live checks. That reduces opaque upgrades. It does not promise crash-free production.
Use the matrix to read the reason. A watch, blocked, refused, or n/a cell can be the correct answer when the reason is named and linked.
Not as a shipped product path yet. The reverse-reconcile design defines authority, scoped write-back, attribution, and round-trip proof. The product still needs a gated command and live proof.
Yes. Variants explains exactly which changes need a new base and which fit a derived ConfigHub variant.
Yes. Start with a read-only discovery or import. Review the sources, targets, objects, labels, and owners. Then keep the imported Units, create a recipe, or build a managed application.
Use the public catalog when a reviewed base variant exists. Use plain Helm when the chart still needs a better base variant or limitation decision. Variants explains when to create a new base and when to create a derived ConfigHub variant. Ask for managed help when private charts, teams, approvals, fleet operations, or production responsibility enter the path.
cub installer uses declared inputs and named bases instead of Helm's free-form --set model. Today cub rejects those Helm habits safely, but the errors are still too opaque. Use the migration guide until the CLI teaches this directly.
The adoption audit lists places where cub is harder than Helm today. They include defaults, one-value changes, direct upgrades, CRD ordering, uninstall, and rollback. Use Helm when one of these gaps blocks a reliable cub path.
The catalog does not make one claim for all 100 charts. Some are ready to try. Others need cluster prerequisites, operator review, or a better base.
No. Claims are per chart, version, base, values path, test, and target profile. A new values file or overlay needs its own render, scan, receipts, and live evidence.
Not yet. The top-20 has the strongest evidence. The top-100 has clearer readiness records. Most top-500 entries remain analysis and triage data until they gain recipes, bases, and receipts.
Public catalog browsing, local render checks, and catalog package setup are free or low-friction. Private catalogs, teams, approvals, application variants, promotions, fleet operations, and production responsibility are ConfigHub-managed.
Retained versions stay pullable from this catalog's own registry, with their receipts unchanged. The full retention reasoning is recorded in how the catalog is built.
How the catalog is built · Registry migration guide · Component Catalog
The RBAC report tests every committed default render without a cluster or another Helm run. A live example removes unnecessary Secret access. It requires approval, publishes the reviewed objects as OCI, and verifies the Argo CD result on Kubernetes.
Send the public chart and values that expose the problem. The expected response is a public fixture and a pass, watch, blocked, refused, or routed gap with evidence.
Start by comparing the rendered objects. Inspect cluster prerequisites, lifecycle steps, image pulls, controller status, and workload health. Then classify the problem as a recipe gap or a cluster runtime gap.
No. Signatures help integrity and transport. Trust also needs signer authority, policy context, scans, gates, and live evidence. Keep that boundary visible.
No. Some decisions stay with a person, and the records say which. Every production disposition names its decision and its owner. Charts that need a custom discussion are marked in the matrix rather than automated over.
No. Keep credential material outside the render. For affected charts, the package default now uses an existing Secret and renders no shared password. The page gives you a command to create fresh Secret material before apply. Fixed-password demo bases are explicit, non-default choices. The published check covers 12 selected defaults with known credential behavior; it is not a catalog-wide credential audit.
Plain kubectl apply does not prune. The no-controller cub-direct path can orphan removed resources unless it uses kubectl apply --prune with a safe selector or allowlist, or another explicit delete-set. Argo CD and Flux can remove omitted objects only when pruning is enabled. Argo CD automated pruning is off by default; a Flux Kustomization uses spec.prune: true.
Prune gap proof · Deployment path · Argo CD pruning · Flux pruning
Not safely yet. A plain apply of a bundle that contains both a CRD and a custom resource can apply the custom resource before the CRD is established. The no-controller path needs CRD-first ordering and a wait/retry step, or a controller that handles ordering.
No. The current live gap proof shows cub-scout detects replica drift but misses container environment-variable drift. Drift detection is valuable, but it must state field coverage until pod-spec coverage is complete.
cub's managed delivery uses server-side apply. If someone edits the same field by hand, Kubernetes can block cub instead of silently overwriting the change. That can be safer, but the CLI must explain it and offer a clear reconcile or force path.
| Result | Next step |
|---|---|
| The Catalog already covers the case | Use its retained package, useful configuration, setup instructions, and evidence. |
| The review finds a values problem | Correct the value and render again. Keep the new object hash with the review. |
| The review finds a credential surprise | Do not deploy it. Replace the literal or placeholder with an existing Secret, then check the reviewed objects again. See one NGINX configuration go from local finding to ConfigHub gate to promotion, find configurations that use existing Secrets, or read the credential limitation. |
| The render is surprising | Do not deploy it yet. Compare it with the defaults and the configuration you run now, correct the cause, then render and check it again. |
| The chart does not expose the required field | Keep the chart when possible and record the smallest object change as a ConfigHub variant. |
| The configuration needs hooks, CRDs, Secrets, or setup work | Choose an explicit owner and order. Use only a delivery route whose evidence covers that work. |
| The result should remain portable | Keep the YAML and review record locally, or publish the reviewed files as OCI. |
| A team needs history, promotion, or rollout | Save the reviewed result in ConfigHub, then create variants, approve changes, publish releases, and compare desired with live state. |
Additional references: Helm investigation details · hooks and CRD setup · delivery limitations · checks and publication receipts · promotion and fleet examples