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. See the model
A component is the software being shipped. A variant is one named configuration of that component.
Component: payments-api
Variants:
payments-api/base
payments-api/dev
payments-api/staging
payments-api/prod-us
payments-api/prod-eu| Term | Meaning |
|---|---|
| Component | The thing you care about: Redis, ingress-nginx, payments-api, or a platform slice. |
| Variant | One named configuration of that component: base, dev, staging, prod-us, prod-eu, or customer-a. |
| Base variant | A configuration rendered from Helm. Use it when values, chart version, CRDs, storage, HA mode, or Secret strategy change the Kubernetes objects. |
| Derived variant | A ConfigHub configuration made from an existing base. Use it for environment, region, target, labels, approvals, and scoped post-render changes. |
| Promotion | A controlled way to carry a reviewed change from one variant to another, with a preview before anything is applied. |
The team can then answer four questions. Which configuration are we using, where did it come from, what changed, and is it safe to promote?
Recipe, base and variant
Three words name three different stages. A recipe is chosen before flattening. A base is what flattening one recipe gives. A variant is a copy of a base with changes.
| Word | What it is | Example |
|---|---|---|
| Recipe | A pinned choice before flattening. Its provider records which target and use case it is for. | A Catalog Helm preset with recorded values, or an AICR recipe selected by service, accelerator, and platform. |
| Base | The exact objects produced from one recipe, with their digest, source link, and evidence. | One rendered Helm preset, or the Argo CD Applications produced from one AICR recipe. |
| Variant | A recorded change to a base for an environment, region, customer, or policy. | Development, staging, and production revisions linked to the same base. |
Four things called base
The word base names four different things on this site and in the CLI. Here is each one.
| Where you see it | What it means | Example |
|---|---|---|
--base flag | Picks a preset when you render or upload a package. | cub installer setup --base reuse-existing-secret |
| Base variant | The reviewed Helm render itself: the chart, values, and captured objects. | Redis default, Redis reuse-existing-secret |
| Package base | The folder inside the installer package that holds one preset's files. | packages/bitnami/redis/25.5.3/bases/default |
| Base Space | The ConfigHub Space created when you upload a base variant. It has no Target. | cub variant upload labels it Variant=base |
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.
Two words worth defining
A recipe pins the source and the choices that produce exact objects. That is a Helm chart and its values, or an AICR recipe in its native format. Literal sources like OCI and plain YAML have no recipe; they are already an exact configuration.
Declared inputs are the named settings a package exposes for you to fill, such as a namespace or an existing Secret name. cub installer doc <pkg> lists them; a value outside that list is a hard error, not a silent Helm --set.
Change a config safely decides where a change belongs, follows a safe flow with its commands, and opens worked examples.
2. Tell what set a field
Use these steps to trace which layer actually set a field you are looking at.
- Open the base Space's
installer-recordUnit to see which package was uploaded. Catalog demo Spaces may also containreadmeand render-intent Units that explain the chart, values profile, and required setup. - Open the package's Helm render-intent record to see which Helm values and render settings produced the starting objects.
- Open the Kubernetes Unit's revision history for changes made in ConfigHub.
- Open the derived Space's upstream link to see which base it started from.
- Treat a value seen only in the live cluster as drift until the team records it as an intended revision or removes it.
Where each setting lives
There are four places to look.
| Place | What belongs there | How to see what is set now |
|---|---|---|
| Helm values | Choices that change what Helm renders: components, object count or fields, storage mode, CRDs, ingress, Secret strategy, hooks, service exposure, or topology. | Open the base variant's valuesProfile link in its HelmRenderIntent, then open the rendered YAML it produced. |
| ConfigHub changes | Exact post-render edits when the base is right but an environment, region, customer, policy, image, label, resource, or other object field must differ. | Open the Unit revision history or derived variant. The public catalog base itself has no ConfigHub edits. |
| Install work | Required Secrets, CRDs, target facts, hooks, setup jobs, certificates, cloud accounts, and other work around the objects. | Open the base variant's prerequisites and lifecycle steps. These are not hidden as values or post-render edits. |
| Live cluster | What actually ran. | Compare observations with the reviewed Units. A live-only edit is drift until it is recorded as an intended ConfigHub revision or removed. |
One field should not have two silent owners. If a new Helm render and a ConfigHub revision both change the same field, review the overlap before promotion, then read the full command walkthrough.
3. Understand a chart preset
The claim
The catalog does not try to prove every possible Helm values combination. Most charts expose too many switches for that to be useful or honest.
It claims something narrower and more practical.
- Users keep their Helm charts.
- The catalog offers ready-to-use chart presets for common operating choices.
- Each chart preset records the values and render inputs that produced it.
- The rendered Kubernetes objects are captured as generated output.
- Hooks, CRDs, setup jobs, generated Secrets, cloud accounts, and target prerequisites are recorded with the chart preset.
- Tests, receipts, and chart pages say what is proven, blocked, refused, or still waiting for more work.
| Chart preset | Typical reason |
|---|---|
default | Start from the chart author's normal path. |
no-crds | The target cluster or another controller owns the CRDs. |
crds-enabled | The package owns the CRDs for this install. |
reuse-existing-secret | Keep secret material outside the chart render. |
server-only | Run one useful component instead of the whole chart stack. |
ha | Use a reviewed high-availability configuration. |
internal-service | Keep the service private to the cluster or platform. |
What a chart preset records
| Item | Why it matters |
|---|---|
| Chart source and version | The upstream input is pinned. |
| Values profile | Reviewers can see which values were used. |
| Release name and namespace | The render can be repeated. |
| Capability profile | Kubernetes API assumptions are explicit. |
| Source lock | The chart and dependencies can be traced. |
| Render intent | The compact machine-readable record of the render inputs. |
| Render variant | The captured Kubernetes objects produced by the chart preset. |
| Installer package OCI ref | The public package address users pull with cub installer setup --pull oci://.... |
| Package base | The generated package users can inspect and try. |
| Evidence lanes | The checks, receipts, scans, and live observations for the row. |
| Chart extras | Hooks, CRDs, setup jobs, generated facts, target facts, and other work outside plain YAML. |
The short model
chart version
base variant: named Helm render choice
render intent: inputs needed to repeat the render
render variant: Kubernetes objects captured from that render
managed variant: ConfigHub version made after the render| Term | Plain meaning | Example |
|---|---|---|
| Preset / base variant | A named way to render a Helm chart. Preset is the public word; base variant is the repo word. | Redis default, Redis reuse-existing-secret |
| Render intent | The inputs needed to repeat that render. | chart version, values file, namespace, release name, capabilities, source lock |
| Render variant | The captured output from that render. | Redis release-objects.yaml plus variant-revision.yaml |
| Managed variant | A ConfigHub version made after the rendered objects are uploaded. | dev, staging, prod, per-region, per-customer |
Managed variant here is the same idea as the derived variant used elsewhere on this page; the render-intent guide uses its own name for it.
4. See what is inside ConfigHub
- Unit is a versioned, diffable piece of configuration. Rendered Kubernetes objects become Units when they are uploaded.
- Space groups the Units for one managed configuration, such as a base, development environment, production region, or customer.
- Base variant is the reviewed starting configuration. For a Helm source, it matches a supported render shape such as
no-crdsorreuse-existing-secret. - Derived variant is a ConfigHub clone for a specific environment, region, customer, or target. Its changes are exact object changes; Helm is not rendered again.
A base Space has no Target. cub variant upload creates it labeled Variant=base, and it holds one Unit per rendered object until you choose to deliver it. The upload skips Secrets, so a Secret gets no Unit.
What the package contains
An installer package is the catalog artifact for one chart version.
- The package metadata and
installer.yaml. - The available preset chart configurations, called bases in the repo.
- The files needed to render each supported preset locally.
records/index.yaml, which lists the supporting record for every base.records/<base>/source-and-intent.yaml, which connects the source, exact objects, requirements, lifecycle work, checks, and evidence.records/<base>/helm-render-intent.yaml, which records the Helm chart, version, values, namespace, release name, capabilities, and source lock.
Files under records/ are supporting information, not Kubernetes objects; do not apply them to a cluster.
5. Read the details
Creating variants explains the rules. cub variant commands lists the current commands. Variant promotion receipts show the current evidence.
The configuration model and vocabulary guide defines every term on this page. After upload walks through the exact commands. Helm chart presets and values and Helm render intents cover the render-time record in full.
The ConfigHub data model covers Units, Spaces, and targets in full. Choosing base variants, derived variants, and delivery changes and the custom overlay example cover routing in more depth. Change an OCI package without ConfigHub and installer OCI packages cover the package format.
Deciding whether to flatten covers the verdict a base needs before it ships as a bundle.