How ConfigHub works explains where these verbs fit, from a free check to a governed release.
Try it now
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.
# one image into your org
$ cub variant upload --component redis --variant base oci://…@sha256:…
# place it on a cluster's target; a release belongs to its target
$ cub variant create staging redis-base --target staging/target
# release by digest; your reconciler pulls it
$ cub release publish redis-staging
# move the reviewed change up the tree
$ cub variant promote redis-stagingThese are ConfigHub's own verbs, and each has its own section below. Start from a stack instead for the plugin's own commands.
1. Release
Release publishes an approved configuration by digest, so your reconciler pulls exactly that image instead of a hand-pushed bundle.
| Level | Do this | Command | What you get |
|---|---|---|---|
| Advanced | Attach a cluster that pulls | cub cluster up --name demo-dev | A kind cluster with Argo CD, wired to demo-dev/target in ConfigHub, so target-bound releases can reconcile. |
| Basic | Upload one image, or one app, as a base | cub variant upload --component redis --variant base oci://…@sha256:…cub app upload shop-web --run | A base variant you can clone. Nothing is deployed yet. |
| Basic | Place it on a cluster | cub variant create demo-dev metrics-server-base --target demo-dev/target --space-pattern "template:metrics-server-demo-dev" | A deployment variant, cloned from the base into a Space named metrics-server-demo-dev, bound to that cluster's OCI target. |
| Basic | Release it | cub release publish metrics-server-demo-dev | An OCI image in ConfigHub's registry, pinned to its digest, for your reconciler to pull. |
Once released, ConfigHub's record of the approved target stays put, and Argo CD or Flux applies the release and reports the live result.
2. Promote
Promote carries a reviewed change from one environment to the next. Variants decides whether the change belongs in the base or in one derived variant, and what protection means.
| Level | Do this | Command | What you get |
|---|---|---|---|
| Basic | Change one field in a base | cub function set --space cart-base --unit retail-deployment-cart set-replicas 2 --change-desc "Two cart replicas" | A new revision of the base. Every deployment cloned from it now shows as behind. |
| Advanced | Promote the change | cub variant promote cart-demo-dev --dry-run, then without --dry-run | The deployment takes the base's change and keeps what it protected; anything withheld appears in cub unit conflicts. |
A dry run shows exactly what would change before anything is applied.
3. Gate and approve
Checks inspect a candidate. In cub v0.5.7, approval is an attestation about selected revisions in a Space. A ChangeWorkflow can require qualifying attestations before a promotion stage or release; merely recording one does not install a gate. Production approval is separate from schema and placeholder checks.
| Level | Do this | Command | What you get |
|---|---|---|---|
| Advanced | Review how to configure the approval gate | cub changeworkflow create --help | Declare AttestationPrerequisites in the workflow file and reference them from stage Prerequisites or ReleasePrerequisites. Bind the reviewed workflow to the ChangeOrder before relying on enforcement. |
| Advanced | Record the reviewed approval | cub variant approve cart-demo-dev | Records Approval attestations for the current revisions of Units with Targets in this Space. A Space with no Targets records nothing unless you add --all. Review that whole selection first. Identical-content later revisions can remain covered; a changed-content revision needs a qualifying approval. The configured workflow decides whether the gate is satisfied. |
4. Roll back
Roll back moves a Unit's head to a revision that already ran, so publishing again releases exactly those bytes. It restores configuration only. It cannot undo a database migration or any other change outside those objects, so review data changes before you roll back.
| Level | Do this | Command | What you get |
|---|---|---|---|
| Advanced | Roll back | cub unit update --space cart-demo-dev retail-deployment-cart --restore 2 | The Unit's head moves to the recorded revision; publish again to release it. |
Rehearse a rollback before you need it, or follow the Redis rollback example.