Build a stack from certified parts

Get a stack

You want a stack — a set of configs checked for conflicts before they render. Here is how you get one.

1. Want a ready-made one?

Pick a shipped stack and certify it in one command. cub stack sandbox eks-inference renders 130 objects from eight certified bundles, each hash-verified against its receipt. Thirteen ship, from a full inference platform to three services; see the stacks that ship.

2. Already have a Kubara platform?

Turn its own output into a stack with cub stack from-kubara ., rendered with the values Kubara generated, so certify judges the platform you actually have. Build a platform walks the whole Kubara adoption journey, generate to deploy.

3. Composing your own?

Author a manifest from catalog parts by digest, or let an assistant propose one from images that already exist and were checked. Then run cub stack certify until it holds together; see the manifest and the loop.

4. Ready to run it with a team?

Upload the stack, place it on clusters, then promote and gate it in ConfigHub. That is where a stack becomes a platform. The taxonomy note sets out these paths in full.

What a stack is

A stack is a set of parts named in one manifest and checked before any of it runs. A platform is what a stack becomes once it is running under governance with your apps on it. A fleet is that stack and its apps placed across many clusters as data. So a stack is what you get and certify, a platform is the outcome once it runs, and each cluster in a fleet becomes its own platform when it runs.

An app, in turn, is “a workload you bring,” as Apps on a platform defines it. Upload, place, govern below is how an app's stack becomes the platform it runs on.

Stacks span a wide range. One provisions a cloud network, a cluster, and a GPU runtime from an empty account. Another is three services on a cluster you already run. The plane on each component, hub, mgmt, or workload, is how a manifest says which level it works at. The list further down is sorted by that level, not flat.

An AICR-generated AI platform is a stack in this same sense, composed from Argo CD Applications instead of a manifest here. Try AICR inspects one without a GPU.

Creating a stack: the manifest and the loop

A stack manifest names its components. Each component is either a bundle pinned by digest with a receipt, or a render or authored file of rendered objects the stack owns. A bundle is pulled once and hash-verified against its receipt before a single object parses.

Each component carries a plane, its altitude, and an order that sequences it within that plane so CRDs land before the resources that use them. Bindings between components live in the manifest too, so upload builds the links from data.

There is no continuous validation. It is a loop: edit the YAML, run cub stack certify <file>, read what it names wrong, fix it, run again. Certify is the contract you build against. Read the manifest specification.

What certify checks

Two shipped stacks exist to be refused. metrics-double carries two copies of metrics-server that claim the same nine objects. conflict-demo carries two authored components that define one ConfigMap differently.

Adapting a stack

Adaptation happens in two places, and neither needs a new verb.

You adapt by hand before you upload. When certify refuses, change either side. Adapt the app, its ingress class or a secret it pulls, or grow the platform by the service the app needs. Re-run certify until it passes. The app and the platform negotiate through certify, and the platform ends up shaped by its apps. The kubara-shop-first-try refusal above becomes kubara-shop-platform this way.

You adapt again in ConfigHub, after upload. Variants explains when that is a new base and when it is a derived variant. See the operate verbs.

Becoming a platform: upload, place, govern

cub stack upload <name> --run certifies first, then builds one base Space per component in ConfigHub and the links the manifest declares. Without --run it prints the plan and changes nothing. From there ConfigHub's own verbs take over: cub variant create places a base on a target, cub release publish releases it by digest, and cub variant promote moves a reviewed change up the tree.

A fleet places a stack across many clusters as data. cub fleet up meridian scaffolds ten regional cluster Spaces, uploads twenty component bases, and places and releases their deployments through those same governed verbs. cub fleet status meridian then recomputes four attention tiles, blocking gates, unreleased changes, upgrades available, and outstanding rollouts, from the queries the product runs. The fleet model is specified alongside the stack manifest.

A stack can also leave as OCI with no account. cub stack publish <name> --out oci://… publishes it as an index of images with the manifest and verdict attached, and cub stack sandbox <name> --out oci://… publishes the flattened form a reconciler pulls. Every result is an image. See every OCI shape in one table.

Run it

These four run here. The ten-minute demo walks all of them end to end, from one chart to a governed fleet.

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

# CERTIFIED, 130 objects, no cluster
$ cub stack sandbox eks-inference

# REJECTED: nine objects claimed twice
$ cub stack certify metrics-double

# a real Kubara platform, as a certified stack
$ cub stack from-kubara ./my-kubara-platform

# an index of images
$ cub stack publish shop-platform --out oci://REGISTRY/shop-platform:v1

Every manifest on this page ships in the plugin: the stacks directory, with eks-inference as the worked example and the ten-minute walkthrough. The site links these files and never copies them, so the file you read is the file the plugin runs.