Needs a ConfigHub account
Uploading a reviewed configuration into ConfigHub is the step that needs an account. From there you release it so a cluster pulls it, and promote it across environments, with the source, checks, approvals, and history kept beside it.
Use the Catalog or Check my config before you sign up. Continue here when your team needs the same answer tomorrow, in another environment, or after the next change.
This is also where public configuration chains into your private org: a base you upload keeps sending you fixes while protection keeps the values you chose. ConfigHub shows exact diffs, promotes reviewed changes from development to production, and compares approved configuration with your clusters.
Upgrading a chart with hooks or CRDs? Check the upgrade against the next environment before promoting it, then follow the base through staging, approval, and release.
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.
Start with what you have. These paths work with cub directly or with an AI agent beside you. ConfigHub keeps the reviewed configuration and its changes; your delivery controller applies it to the cluster.
Follow the import and deployment steps · Try the official tutorial
Inspect with cub scout · Argo CD onboarding · Flux onboarding
Live discovery needs cluster access. Keep credentials out of imported configuration.
Follow release and promotion · Review a candidate before promotion
Follow the fleet workflow · Release, gate and roll back
Your controller handles application rollout behavior, including canary traffic where configured.
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. An entry without a certified image has no such record. 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.
Deployment commands · The ConfigHub data model
When the work carries private inputs, production responsibility, multiple teams, policy, SLA, or fleet scale, the Upgrade guide describes what the commercial product governs.
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.
ded2b7c2624c74ae1dce2a947ad9d99a32a62f5114361970af61c9ca51449345.oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/byo-nginx-ai-values:24.0.2-r001 back produces the same object-set hash. The OCI digest is sha256:34af6a50b952d1a168a5cad614ef47f652cf44b11806a93bf6cc7a79c6e9c683.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.
Take a config further lists each job ConfigHub keeps for you, from comparing environments to a fleet rollout, and how to take a Catalog entry into a stack or into ConfigHub.
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.