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.
1. Choose a tool and start
Five tools cover the whole model. Pick by what you want to do right now, and move between them as the work grows.
| Tool | Use it when | What you get |
|---|---|---|
cub config, the workshop plugin | You want the free path on a config, an app, or a stack: check, render, publish, verify, and upload. | The objects and what a source hides, a CHECKED or REFUSED verdict on a stack, and a verified image with --out oci://…. No account. |
cub installer | You want a maintained catalog package with named bases, receipts, and an upgrade path. | Render a reviewed preset and deliver it as a controller-native OCI, verified as it is pushed. Free on any catalog package. |
cub helm | You have an arbitrary chart and want a fast render or to store it in ConfigHub. | cub helm template renders locally; cub helm install records the source and rendered base as Units. Preparation, not a catalog entry. |
| The browser check | You want to inspect rendered YAML without installing anything. | An object review in your browser and a handoff prompt for your own AI. Is my configuration right? |
| Your own AI assistant | You want an assistant to run the investigation and keep it tied to records. | It renders, checks, proposes a candidate, or completes the ConfigHub handoff; you still check the files and diffs. Your assistant |
cub server install runs ConfigHub yourself, locally, in about twenty seconds, when you want the account path on your own machine.
Why this is more than a fast render command
A fair skeptic asks if this is just helm template with a wrapper. It turns Helm's output into something reviewed, named, and reusable across a fleet. You get variants you can compare, checks you can gate on, and receipts you can cite.
A change becomes safer when it is compared, scanned, and kept as a receipt before it is promoted. Staying on the chart author's supported path also helps, because a departure becomes visible before it reaches production.
Read the fuller argument in why this exists and what you get, or see the free, account, and commercial paths on the Offering page.
Three public jobs
- Catalog answers questions already investigated for a named source and version: retained packages, useful configurations, setup requirements, checks, and known limits. Find a configuration.
- Check my config investigates a new chart, version, values set, OCI bundle, or existing deployment. The browser inspects rendered YAML without sending it to a server, and builds a prompt for your own assistant. Is my configuration right?
- ConfigHub retains an accepted answer, then lets a team make variants, review diffs, promote changes, publish releases, and compare desired configuration with live observations. What ConfigHub adds.
A graduation path, not a day-one choice
You can move through these paths over time. You do not need the full catalog model on day one.
| Stage | Command path | Result |
|---|---|---|
| Inspect | cub helm template | Render an arbitrary chart locally and see the Kubernetes objects. |
| Adopt a chart | cub helm install | Store a HelmSource Unit and the rendered base Units in two ConfigHub Spaces. |
| Adopt files or OCI | cub variant upload | Load rendered files or a literal configuration OCI into ConfigHub Units. |
| Use a maintained entry | cub installer setup --pull <installer OCI ref> --base <base> | Start from a reviewed package base with locks, values, receipts, and checks. |
| Operate | cub variant create, cub variant promote, releases, scans, approvals | Manage reviewed objects as ConfigHub Units and derived variants. |
Here is what the command does. cub installer is an open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally, leaving delivery to kubectl, Argo CD or Flux. The generated scripts stop before doing any work when the plugin or kustomize is missing.
When your chart is not in the catalog
When the exact chart and variant you want is not in the catalog, you render your own and bring it in. ConfigHub never needs one of our images to run a chart. Which path you take depends on what you mean to do.
- Just check it. Render it with
cub helm templatelocally, or use the browser check. No packaging, no account. - Render and deliver it your way. Your own chart has no catalog package to pull, so render it with
cub helm template, then deliver the reviewed objects as OCI.cub installerpulls a catalog package that already ships an image; it cannot pull a chart that has none. - Manage it in ConfigHub.
cub helm installrecords the chart straight into Units, and from there you release, promote, and gate it. - Add it to the tested catalog for everyone. Send it through the problem chart template, and a maintainer renders, checks, and publishes it as a base variant.