UNOFFICIAL/EXPERIMENTAL. These are the terms used by the catalog and the technical guides.
Before ConfigHub
- Source package is the input you already use: a Helm chart, AICR recipe, installer package, Kubara or Sveltos configuration, or ordinary Kubernetes YAML.
- Preset configuration is a maintained choice for that source. For Helm it fixes a chart version, values, release name, namespace, capabilities, and other render inputs.
- Render intent records everything needed to reproduce one Helm render. It also names prerequisites and lifecycle work such as CRDs, setup Jobs, and hooks. It does not contain the rendered objects.
- Render variant is the captured Kubernetes output for one base and one revision. It points back to the render intent and includes the object inventory and digest.
- Literal configuration OCI contains rendered Kubernetes objects rather than a chart that still needs to be rendered.
cub variant uploadcan read one directly.
For Helm, the two layers are therefore:
chart + values + render context + lifecycle choices
-> render intent
-> captured render variant
-> exact Kubernetes objects
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.
- Component is the app, service, or platform capability being managed, such as
payments-api,redis, oringress-nginx. Today it is represented by standard Space metadata rather than a separate API object. - Base variant is the reviewed starting configuration. For a Helm source, it corresponds to 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.
- Target fact is something the destination must provide, such as an existing Secret, storage class, cloud identity, or installed CRD.
- Lifecycle route records work that ordinary apply cannot safely perform by itself. It says what must happen, in which order, under which delivery system, and which receipt proves completion.
- Receipt records a result for an exact configuration and target. A render receipt, controller result, or workload observation does not prove a broader claim than the inputs it names.
After ConfigHub
- Target identifies where Units are released.
cub cluster upcreates a temporary cluster Space and its server-hosted OCI target for the local examples. - Space release OCI is produced by
cub release publish <space>. It contains the reviewed Units from that Space and has a pull URL such asoci://oci.hub.confighub.com:443/space/my-app. - Delivery consumer is Argo CD, Flux, or a recorded direct path. It applies the Space release without rendering the original source package again.
How the pieces fit
New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.
source package
-> render intent and captured render variant
-> exact objects uploaded as ConfigHub Units
-> base and derived Spaces, diffs, checks, approvals, promotions
-> cub release publish
-> one Space release OCI
-> Argo CD, Flux, or recorded direct apply
-> live observations and receipts
One component with several variants
Component: payments-api
Variants:
payments-api/base
payments-api/dev
payments-api/staging
payments-api/prod-us
payments-api/prod-eu
This lets a team answer concrete questions:
- What differs between the base and
prod-us? - Which environments will receive a base change?
- Did staging pass before production was promoted?
- Which target facts make
prod-eudifferent? - Did an AI-assisted edit stay within the approved fields?
Read Creating variants, How ConfigHub delivers configuration through OCI, Render intents and render variants, Target prerequisites, and What happens to Helm hooks.