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. What ConfigHub adds
Config defines it: “ConfigHub is where a reviewed base becomes shared, governed configuration.” This page explains what that adds once you have an account.
The account path has three steps. Upload brings the reviewed configuration into ConfigHub as a base, stored with its source and review record. Release publishes it so Argo CD or Flux pulls it. Promote moves a reviewed change from development to production, with the exact diff, the approval, and the history kept beside it.
Upload also chains public configuration into your private org. A base you upload can be public, pulled from a shared catalog, while your deployment stays private. When ConfigHub clones the public base into your deployment, links carry your private values into it, and protection keeps the values you chose. Later fixes to the public base, a patched image or a new version, flow down to everything you did not protect. That chaining is the value a plain registry cannot offer. If your CI already renders charts into YAML in git, the recorded journey lands those exact files as governed data, receipted.
Every certified image in the Catalog has been uploaded into a ConfigHub organization as a base variant and checked, so the whole catalog is known to flow in cleanly. Read the lane for the per-image record.
ConfigHub answers the four questions below separately, each on its own evidence, and never lets one stand for another. It links the source to its materialized objects, the destination check to one target, and the live result to one exact release. A retained object or a published OCI never counts as a destination or live pass.
| Question | What ConfigHub retains |
|---|---|
| What do I have? | The source identity, imported files, exact object records, and their history. |
| What will it produce? | The source and intent, materialized objects, object identity, and recorded transformation. |
| Can this destination accept it? | Checks against one named destination, tied to the exact candidate and current destination facts. |
| Did it work? | Results for the exact delivered revision, target, time, and claim that was checked. |
During an upgrade, non-conflicting recorded changes remain. Review a conflict when the new source render and a ConfigHub revision change the same field.
2. See one exact handoff
A worked NGINX example starts with AI-written Helm values. The review keeps the requested three replicas, removes six risky settings, and produces 5 Kubernetes objects.
We calculate one hash from those objects at each step, so matching hashes mean the objects came through unchanged.
- Review locally. The 5 objects have object-set hash
ded2b7c2624c74ae1dce2a947ad9d99a32a62f5114361970af61c9ca51449345. - Publish the OCI. Pulling
oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/byo-nginx-ai-values:24.0.2-r001back produces the same object-set hash. The OCI digest issha256:34af6a50b952d1a168a5cad614ef47f652cf44b11806a93bf6cc7a79c6e9c683. - Upload the base to ConfigHub. ConfigHub reads back the same 5 objects with the same object-set hash, and records the same OCI digest as their source.
- Record the decision. A separate, non-deployable Unit says how each finding was handled. Six fixes were accepted. One remaining emptyDir finding is accepted only for the exact development and staging demonstration, excludes production, and has a review date. ConfigHub records approval of that exact decision revision.
The matching hashes show that the handoff preserves the reviewed objects. The decision record answers a different question: what did we fix, what did we accept for now, and where may this result run? Read the complete decision, promotion, and delivery chain.
Open the plain-English handoff record, the public OCI receipt, or the ConfigHub upload receipt.
Check my config now downloads candidate.yaml and workshop-review.json. Its handoff commands upload the objects with cub variant upload and attach both file hashes. The commands also create a Provider None review Unit in the same Space. Provider None keeps the review beside the configuration without placing it in a deployment release.
If your own Claude, Codex, or other assistant is already running, the same page builds a prompt for it. The prompt checks the downloaded files, asks before writing to ConfigHub, runs the handoff, and reads the stored result back.
3. Continue from the retained answer
Start with the public Promote my config comparison. ConfigHub is the next step when the same proposed object hash must move through named environments with approvals, release digests, and target results.
| Job | What ConfigHub keeps | Start here |
|---|---|---|
| Compare development and production | Both variants, their source relationship, and exact object diff. | Compare environments |
| Promote and publish | The reviewed change, approval, promotion result, and immutable release OCI. | Promotion and OCI examples |
| Roll back | The prior object revision or release digest. External effects remain outside the rollback claim. | Redis promotion and rollback |
| Compare desired with live | The approved desired objects and a separately dated live observation. | Desired and live comparison |
| Roll out to a fleet | The selected targets, waves, approvals, and result for every target. | Fleet examples |
4. Continue with the official tutorial
Create a ConfigHub account when you are ready to save a reviewed configuration. Then continue with the official tutorial to create a development deployment, make a change, add production, and promote the reviewed result.
Read the ConfigHub blog for product ideas, technical explanations, and worked stories.