Browse Operate
Catalog
Config
Stacks
Operate
Docs

Operate

Release, promote, gate, and roll back a reviewed configuration

These are ConfigHub's own operations, the ones you run once a configuration is reviewed. Release it by digest, promote it from development to production, gate a release on an approval, and roll back to exactly what ran. Come here after you have inspected the Kubernetes objects, which may have come from Helm, an AICR recipe for AI infrastructure, cub installer, OCI, or plain YAML.

You can stop with local files, publish them directly as OCI, or upload them to ConfigHub and publish a reviewed release OCI later.

ConfigHub stores your approved configuration and its history. Use it when you need to track changes across environments, require an approval before production, or roll back to a recorded release. Start with what ConfigHub adds.

The same commands run from a free check to a governed release

Whatever a configuration started as, it takes the same steps. The first steps are free and need no account. The next need a ConfigHub account. The last is the commercial product.

TierVerbWhat it doesCommand or surface
FreecheckInspect it: what it installs, whether it is right. No cluster.the Check
Freedeploy (a planned name, not yet a command)Run the reviewed OCI on the Argo CD or Flux you already run.cub installer, or your own kubectl, Flux, or Argo CD
AccountuploadBring it into ConfigHub as a base. Public config chains into your private org here.cub variant upload
AccountreleasePublish an approved, immutable release with history, so the cluster pulls that instead of a hand-pushed bundle.cub release publish
AccountpromoteMove a reviewed change from development to production.cub variant promote
PaidgovernRun a stack under governance: approvals, releases, rollback, drift, a fleet view.the commercial product

A stack adds free commands of its own, certify and sandbox, and a fleet places one across many clusters. Those run today as a plugin prototype. See stacks and fleets.

Every source becomes exact Kubernetes objects and any required setup before it reaches this page. See what each format becomes, and see what happens to hooks, CRDs, and setup work.

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:…

# release by digest; your reconciler pulls it
$ cub release publish redis-app

# move the reviewed change up the tree
$ cub variant promote redis-staging

These 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.

LevelDo thisCommandWhat you get
AdvancedAttach a cluster that pullscub cluster up demo-devA kind cluster with Argo CD, wired to an OCI target in ConfigHub, so releases published to it reconcile.
BasicUpload one image, or one app, as a basecub variant upload --component redis --variant base oci://…@sha256:…
cub app upload shop-web --run		A base variant you can clone. Nothing is deployed yet.
BasicPlace it on a clustercub 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.
BasicRelease itcub release publish metrics-server-demo-devAn 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.

See what ConfigHub adds once you have an account.

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.

LevelDo thisCommandWhat you get
BasicChange one field in a basecub 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.
AdvancedPromote the changecub variant promote cart-demo-dev --dry-run, then without --dry-runThe 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.

Review a promotion before you run it.

3. Gate and approve

Checks inspect a candidate, and apply gates decide whether ConfigHub may apply it. A warning is recorded without stopping delivery, but a blocking gate stops the apply. Production approval is a separate gate from schema and placeholder checks.

LevelDo thisCommandWhat you get
AdvancedGate a release on approvalcub trigger create require-approval Mutation Kubernetes/YAML vet-approvedby 1 --space cart-demo-devEvery Unit in the Space carries an Apply Gate, and a release is refused until it clears.
AdvancedApprove itcub unit approve retail-deployment-cart --space cart-demo-devThe gate clears for exactly that revision. The next change is gated again with nobody re-arming anything.

See gates and scans among the other operations.

4. Roll back

Roll back moves a Unit's head to a revision that already ran, so publishing again releases exactly those bytes.

LevelDo thisCommandWhat you get
AdvancedRoll backcub unit update --space cart-demo-dev retail-deployment-cart --restore 2The 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.