From one chart to a governed fleet in ten minutes

Local Guides and inspection

Finish with files you can inspect and keep. The walkthroughs include setup, direct commands, an assistant task, expected results and a failure case. Start with the job you need; no ConfigHub account or cluster is needed.

Assistants run the same commands. Inspection uses the repository adapter; the cub Guides use the Workshop plugin. Actual live-chat API integration remains a separate route.

Try it now

Install the plugin, then check a chart. It costs nothing and touches no cluster.

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 plugin install confighub/cub-workshop@v0.6.61
cub config check redis

cub config check redis reports the fourteen objects it installs, the namespaces that must already exist, and the lifecycle work it hides. Nothing is applied.

1. config — see what one chart installs (free)

cub config check redis

The check lists every object the chart installs and the setup it hides, from the namespaces that must already exist to the CRDs, hooks, and webhook certificates it needs. A plain helm install shows you none of that until it fails. Check my config runs the same review on your own chart and values.

2. app — does this workload need a platform? (free)

cub app check hello-standalone
cub app check shop-web
cub app score shop-web

The first workload is standalone and delivers straight from OCI. The second needs an ingress controller, cert-manager, and a Prometheus operator, which the web-platform stack carries exactly. cub app score exports the workload to Score. Apps on a platform carries this in full.

3. stack — check a whole stack, and watch a refusal (free)

cub stack sandbox eks-inference
cub stack check metrics-double

The first checks a real inference stack, 130 objects across eight bundles, with no cluster and no cloud account. The second fails, because two of its components claim the same objects and the check refuses a stack that cannot hold together. Stacks defines a stack as “a set of parts named in one manifest and checked before any of it runs.”

An app tells the platform what it needs

The check reads what each authored app needs from the platform under it, off the app's own objects, and refuses a stack that does not carry it.

$ cub app check shop-web
needs an ingress controller, cert-manager, a Prometheus operator

$ cub stack check kubara-shop-first-try
=> REFUSED - the Ingress asks for class nginx, the platform runs Traefik; nothing provides the operator

$ cub app check shop-web-kubara
the app adapted: Traefik's class, a secret through external-secrets

$ cub stack sandbox kubara-shop-platform
=> CHECKED - the platform grew by external-secrets, every need carried

The app told the platform what it had to be, and the platform grew by one service to carry it. Apps walks the same negotiation step by step.

A Kubara platform becomes a stack

When a Kubara platform already exists, its own output becomes a stack, rendered with the values Kubara generated. The check then judges the platform you actually have rather than the catalog's copy of its parts. A platform, as Stacks and fleets defines it, is what a stack becomes once it runs under governance with apps on it.

$ kubara --work-dir . --config-file config.yaml --env-file .env generate --helm

$ cub stack from-kubara . --app shop-web-kubara
renders each umbrella chart with its values; one owner per object

$ cub stack check ./confighub/stack.yaml

$ cub stack upload  ./confighub/stack.yaml --run

Kubara platforms walks the whole Kubara adoption journey.

3b. Hand it on as an image (free, any registry)

# or any registry you can push to
$ docker run -d -p 5001:5000 registry:2

$ cub config check redis --out oci://localhost:5001/demo/redis:v1

$ cub config verify oci://localhost:5001/demo/redis@sha256:…
the digest it printed

$ cub stack publish shop-platform --out oci://localhost:5001/demo/shop-platform:v1

cub config check --out writes the render as an image with its receipt attached, and cub config verify re-checks that image from nothing but its digest. cub stack publish does the same for a whole stack. Your Flux or Argo CD then pulls exactly that image.

4. fleet — generate a governed fleet from two manifests (account)

This step needs a ConfigHub organization you can write to. Everything before it was free.

cub fleet up meridian
cub fleet age meridian
cub fleet status meridian

cub fleet up builds ten cluster Spaces, uploads twenty components, and releases 125 deployments across them. cub fleet status then shows where each cluster needs attention, from blocked gates to unreleased changes and pending rollouts. Nothing runs on a real cluster here; the fleet is governed in ConfigHub until you attach one with cub cluster up.

What to take away

You went from checking one chart to a fleet governed in ConfigHub, and the first three steps cost nothing. The plugin gives you the checks; releasing, promoting, and gating are ConfigHub's own.

These four commands sit on top of ConfigHub's released verbs, and they will keep changing as we do. The inference platform was checked on simulated GPU capacity. It has not run on a real GPU.