Ops Guide · Config Workshop

Before Ops

The app needs a selected chart/base, any customised variants, and a target or delivery path. If those choices are still open, start with Helm Ops Catalog, Variants, or Apps.

Fleet Source Of Record

The strongest operations use case is not one person running one command for one workload. It is a platform team knowing what a whole fleet should run, then reconciling that desired record with the clusters.

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. The install-time surface stays small and restricted, so upgrades do 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 the exact owner, target, checks, rollout order, and current evidence for an NGINX application, Kube Prometheus Stack, and a Kubara platform configuration.

This is why the site keeps separating package OCI from delivery OCI. The package is the vetted release you start from. The delivery artifact is what a controller reconciles after ConfigHub has recorded the desired state.

The operations

Status legend

available runs today. watch has evidence plus a named limitation. Planned work needs product, key, policy, or SLA decisions beyond the public proof corpus.

A green GitOps sync is not the same as a working application. Use observation receipts when the claim depends on live state.

Diff before you ship

available

review the variant's object diff vs its base · ConfigHub · free tier

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: change-routing-before-oci

Scan and gate

available

function scans + safe-ops over rendered objects · free locally · paid for managed policy

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

See: data/external-scan-lane

Release a prepared variant

watch

cub variant promote <space> · Apps SDLC · ConfigHub Server

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

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: data/variant-promotion · prometheus-overlay-promotion-example

Deliver via OCI + GitOps

available

publish content-addressed OCI; a controller reconciles · free to run · standard Argo/Flux

Publish the variant as an OCI artifact, which is a digest-pinned delivery bundle. Argo or Flux can pull that bundle and reconcile it. A green local apply is not the same as the controller reconciling; both are recorded separately.

See: chain-of-proof · data/runtime-gitops

Observe the live result

available

record live evidence after delivery · cub-scout · bring your own 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, use observation to check what actually happened. The receipt says what was checked, when it was checked, which namespace or target was observed, and whether the desired objects matched what the cluster reported.

See: verify-it-yourself · why-synced-is-not-working

Rehearse rollback before you need it

watch

compare live state with a previous approved desired state · ConfigHub revisions · cub-scout rehearsal

cub unit diff <unit> --from=PreviousLiveRevisionNum --to=LiveRevisionNum
cub-scout compare three-way --dry-from <previous-render.yaml>

You see the difference between the current live app and the previous approved state. Today this is a rehearse-and-review path; exact rollback automation depends on the app, target, and any irreversible lifecycle steps.

See: day2-upgrade-rollback · cub-scout-diff-design

When Ops Becomes Managed Scope

When the work carries private inputs, production responsibility, multiple teams, policy, SLA, or fleet scale, the Upgrade guide describes the managed boundary.