# What ConfigHub Workshop is

ConfigHub Workshop is three things.

## 1. A verified catalog

A catalog of tested configuration, all in one form. Helm charts, AICR recipes, OCI
packages, plain YAML, Kubara-generated platforms, and Timoni modules all come
out the same way: as an OCI image of the exact Kubernetes objects, with the
install order, the hooks, the CRDs that must land first, and the things a
deployment needs to know (which webhooks need a certificate, which namespaces
must already exist) kept alongside, and a receipt that says what was checked.
Today: 112 components, 139 versions.

- **Any OCI client can pull an image**: Flux, Argo CD, kubectl, or oras, by
  digest, or by a stable catalog name.
- **Images combine easily and safely.** Every image has been loaded into
  ConfigHub and checked the same way, so you can combine several of them into
  one platform without surprises, and the check reruns whenever the catalog
  changes ([the record](../../data/confighub-ready/summary.md)).
- **Updates reach you without losing your changes.** When the catalog fixes an
  image, your copy in ConfigHub gets the fix, and the settings you changed stay
  yours.

Every image is verified, certified, and signed:

- **Verified**: the image's bytes match its receipt. `cub config verify` checks
  that, and refuses an image that has no receipt.
- **Certified**: the receipt names what was checked and what was not. It never
  means "works on your cluster."
- **Signed**: who published it can be proven, with a key today, keyless next.

**What you can do:** pull any tested configuration as an image, run it with the
reconciler you already have, and prove afterwards that what ran is what was
checked.

**What problem this solves:** you find out what a chart does to your cluster by
applying it, and when something breaks, "what actually got deployed, and who
checked it?" has no answer you can prove.

## 2. Stacks and platforms on demand

You describe what you want, a web platform with monitoring and your shop app,
and get it as a list of parts the catalog already tested. Before anything runs,
one command checks the parts fit together and refuses if two of them fight or
something is missing. Then you run it on your own clusters, or ask ConfigHub to
run it across many. Your AI assistant can pick the parts for you. It can
only pick from images that already exist and have been checked, and the same
check runs before anything renders, so a bad guess is refused rather than
deployed.

Examples that ship today:

- **eks-inference**: an inference platform on EKS, eight certified parts across
  cluster, management, and workload planes, proven up to the point where a GPU
  would be needed. The stack is described in
  [one manifest](https://github.com/confighub/cub-workshop/blob/main/stacks/eks-inference.yaml);
  its parts and receipts are [here](../../data/certified-bundles/eks-inference-stack.md).
- **kubara-platform**: a developer platform generated by Kubara from tested
  catalog parts, with two applications running through it on four clusters
  ([manifest](https://github.com/confighub/cub-workshop/blob/main/stacks/kubara-platform.yaml)).
- **shop-platform**: a web platform with monitoring, a message queue, and the
  shop app, composed by an AI assistant from this site alone and certified in six
  minutes ([manifest](https://github.com/confighub/cub-workshop/blob/main/stacks/shop-platform.yaml),
  [the recorded run](https://github.com/confighub/cub-workshop/tree/main/proofs/assistant-composition-2026-09-02)).
- **observability-base** and **data-services**: a monitoring platform, and a
  cache, database, and queue tier, each certified from catalog parts
  ([all shipped stacks](https://github.com/confighub/cub-workshop/tree/main/stacks)).

Not yet: a hosted place to ask, cloud cluster provisioning and GPU runtime, and
a way for chart maintainers to add their own images.

**What you can do:** describe a platform and get tested parts, checked together
before anything runs, with your assistant allowed to choose.

**What problem this solves:** assembling a platform from a dozen charts is weeks
of trial, and an assistant's composition cannot be trusted without a gate.

## 3. Operate apps, platforms, and stacks correctly in ConfigHub

The `workshop` plugin for cub is the on-ramp. It works on three things, a
config, an app, and a stack, with the same free operations for each: check it,
certify it, render it, publish it, verify it, and upload it into ConfigHub. From
there ConfigHub's own verbs release, promote, gate, approve, and roll back. A platform is what a stack becomes once it is running under
ConfigHub's governance; it is the outcome, not a fourth thing. The image carries
its install order, hooks, and CRDs, so the operations never guess, and a
composition is refused before it renders when two parts claim the same object.
Placing stacks and apps across many clusters, the fleet, is a stretch that
already runs in the plugin. One install:
`cub plugin install confighub/cub-workshop`.

**What you can do:** run the same operations on a chart, a workload, or a whole
platform, from one command line, and be refused when they would go wrong.

**What problem this solves:** a chart, a workload, and a platform are operated
with different tools today, none of them knows the lifecycle work the others
hide, and none of them refuses.