Operate a fleet · ConfigHub Workshop

1. Check the starting point

The application needs a reviewed configuration, any environment changes, and a target or delivery path. If those choices are still open, start with the Component Catalog, Variants, or Apps.

2. Choose an operation

Status legend

available runs today. watch has evidence plus a named limitation. Planned work still needs a product, policy, support, or service decision.

A green GitOps sync tells you the controller accepted the manifest, which is a smaller claim than a working application. Where the claim depends on live state, use observation receipts.

Diff before you ship

available

compare a variant with its base · ConfigHub account

A variant is one named configuration of an app. Its object diff shows exactly which Kubernetes objects changed before anything is delivered. This is the opposite of a values file you have to mentally render.

See: Where changes belong · The day-2 upgrade story

Scan and gate

available

scan rendered objects and stop unsafe releases · local checks; managed policy

Run scans over the rendered objects for privilege, exposure and deprecated APIs. A gate is a release stop, so delivery waits until each finding is accepted or waived with a named reason.

See: Security scan results

Release a prepared variant

watch

preview, then promote a variant · ConfigHub Server

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 variant promote <space> --dry-run -o mutations
cub variant promote <space>

Apps and Variants choose the base, derived variant, and target. We've proven this on Redis, NGINX, and kube-prometheus-stack: previewing the change, updating objects that changed, and adding new ones.

See: Promotion results · Prometheus promotion example

Deliver via OCI + GitOps

available

publish OCI for a GitOps controller · Argo CD or Flux

Publish the variant as an OCI artifact, which is a digest-pinned delivery bundle that Argo or Flux pulls and reconciles. A green local apply and a reconciled controller are different events, so both are recorded separately.

See: How tests support each claim · GitOps test results · Argo CD and Flux guide

Observe the live result

available

check the cluster after delivery · your cluster

cub-scout receipt verify \
  --file <rendered-objects.yaml> \
  --scope namespace/<namespace> \
  --predicate object-set-matches \
  --ttl 1h \
  --out .tmp/object-set.receipt.json

cub-scout receipt validate .tmp/object-set.receipt.json

After delivery, check what actually happened. The receipt names the check, time, namespace or target, and whether the cluster matched the desired objects.

See: Check it yourself · Why a sync check is not enough · What each path can prove

Rehearse rollback before you need it

watch

compare live state with a previous approved revision · ConfigHub revisions and a live check

cub unit diff <space>/<unit> --from=<earlier-revision-number> --to=HeadRevisionNum
cub-scout compare three-way --dry-from <previous-render.yaml>

You see the difference between an earlier approved revision and the head revision. A live run on 2026-10-08 with cub v0.8.7 used each part of this diff command. --to=LastReleasedRevisionNum names the last released revision, so it needs a Unit that has been released. That run saw it fail on a Unit that was never released. The cub-scout line was not run. Today this is a rehearse-and-review path, because exact rollback automation depends on the app, the target, and any lifecycle step that cannot be undone.

See: The day-2 upgrade story · Upgrade and rollback guide · Three-way comparison design · Live run log, 2026-10-08

3. Keep a fleet record

The fleet use case begins when a platform team needs to know what many clusters should run and whether each cluster matches that record.

Use one visible sequence: choose the approved configuration, select targets by label, and preview the exact target list.

Publish to a small wave, then inspect every target before continuing. The Sveltos example records two waves. Managed pause and resume controls are still planned.

A useful record says: this cluster, customer, or environment should run this package release, this preset, these allowed inputs, this target, and these approval gates. The package fixes most choices ahead of time. Only a small, restricted set of settings remains at install time, so an upgrade does not become another free-form Helm exercise.

Fleet area	Who usually owns it	What ConfigHub records
User workloads	Application teams	The approved app variant, target, inputs, policy gates, and release history.
System services	Platform operators	Shared services such as DNS, monitoring, ingress, and storage, with controlled upgrades across clusters.
System configuration	Cluster or fleet systems	Opt-in platform components such as GPU, network, security, and operator configuration, reconciled from a signed-off package and fleet record.

Read the three checked examples for their owners, targets, checks, rollout order, and current evidence. They cover NGINX, Kube Prometheus Stack, and a Kubara platform configuration.

This is why the site keeps package OCI separate from delivery OCI. See every OCI shape and who consumes each one.

4. Open the working App demonstrations

Each row has one checked example with committed evidence. The final column says what is still needed before the same result can be offered more generally.

App	What ran	Broader status	Still to build
Upgrade App	Redis upgrades from chart 25.5.3 to 27.0.0 without losing a post-render replica change, moves through development and staging, reaches two Argo CD clusters, and rolls back.	partial	This is a guarded demonstration and receipt, not a finished ConfigHub App interface.
Hooks and CRDs App	Kube Prometheus Stack passes the recorded CRD, certificate, workload, webhook, and runtime sequence on fresh installs and on an 85.3.3 to 86.1.0 upgrade through Argo CD and Flux.	partial	ConfigHub does not yet select and execute the chart-specific route automatically.
RBAC Review App	One review removes unnecessary Secret access, keeps ConfigMap access, requires approval, publishes OCI, and reaches Kubernetes through Argo CD.	partial	The example does not yet build a complete RBAC binding graph across a live fleet.
Fleet Platform App	Kubara proves one platform target, while Sveltos proves a pilot and two-cluster expansion with separate reviewed OCI digests and drift recovery.	partial	A large mixed-source fleet rollout with failure-based pausing remains open.
AI Change Review App	The example finds an unpinned image and inline API key, clears the reviewed replacement, and proves that approval controls the ConfigHub apply dry-run.	partial	Kubernetes delivery, promotion, rollback, GPU workload health, and live observation have not run for this candidate.

Open the demonstration programme for the steps, evidence, and current limit for every App.