Follow a configuration from source to running

1. Follow one configuration from source to running

Every source reaches the same shape through the same decisions, even when a step does nothing. Helm renders, Timoni builds, AICR and Kubara generate or compose, and literal YAML or configuration OCI is already there. First a source becomes a reviewed base:

source + processing intent
  -> select and lock inputs
  -> materialize exact Kubernetes objects
  -> capture the exact configuration revision
  -> identify lifecycle requirements
  -> decide the flattening lane for the intended path
  -> retain a reviewed base

After the base exists, configuration and lifecycle decisions continue together:

base
  -> derive or update a variant
  -> recheck affected source, flattening, lifecycle, and ownership facts
  -> resolve lifecycle routes for the exact variant, destination, and runtime
  -> compare, test, approve, and promote
  -> publish the release OCI
  -> reconcile objects and perform lifecycle work
  -> observe and record receipts

This is not a one-way build pipeline. A source upgrade rematerializes the base, a variant can introduce a new prerequisite, and a destination can pick a different route without changing the objects.

Across those steps the model does four things and keeps them apart:

• Produce or read the exact objects. Helm renders, Timoni builds, AICR and Kubara generate; literal YAML and configuration OCI are read as they are.
• Keep the identities separate. The base revision, exact object set, source OCI, ConfigHub Unit, and release OCI each have their own digest. A receipt names both sides of a handoff rather than treating unlike hashes as one.
• Plan the work around ordinary apply. CRDs, hooks, setup Jobs, and prerequisites become recorded route intents, resolved once the variant and destination are known.
• Change, promote, and deliver a reviewed variant. A derived variant edits a base after render; ConfigHub reviews, approves, promotes, and releases it, keeping non-overlapping changes on upgrade.

Four questions, asked in order

The same four questions apply to Helm, AICR, Timoni, Kubara, installer packages, OCI, YAML, and retained ConfigHub revisions.

A Catalog entry can shorten any investigation, but it is never a prerequisite for inspecting or processing your own configuration. If the required destination or deployment does not exist, the check is blocked or not run. That is not a failed configuration, a failed workload, or a failed conformance result.

The command at each stage

Each stage is a real command. The first are free and need no account; upload and release need a ConfigHub organization.

A configuration that is unsafe to flatten does not fall out of this model. Its source stays authoritative and its processor runs late, at install time. But the result rejoins at the base step. The render-late objects are retained, derived, promoted, and released like any other base, and only where the objects are produced differs.

Where ConfigHub fits

ConfigHub is where a reviewed base becomes shared, governed configuration. cub variant upload creates the base variant: a Space labelled Component=<name>, Variant=base that holds the configuration as one Unit per resource, with no target. A component is the set of Spaces that share a Component label, so the base is the component's first Space. From there ConfigHub's own verbs release, promote, gate, approve, and roll back.

So one uploaded configuration is one component's base variant held in one Space: the same thing named from four sides. Stacks and fleets defines what comes next: several components compose into a stack, which becomes a platform once it runs under governance with your apps on it. The handoff runs base, then stack, then platform, with an app placed on either.

The full record is in the ConfigHub data model, and the catalog doctrine gives the same lifecycle for every source in more detail.

2. See what each format becomes

Every source ends as the same exact objects, but each takes a different path there and is checked for different things. Flattening is evaluated at each processing boundary, so an AICR Application set can be flattened while the Helm charts it references stay render-late.

Every format above is a real catalog entry you can browse. Open the Catalog and use its Format filter to list one, for example all AICR platforms or the Timoni module.

3. See whether a configuration can be flattened

Flattening means keeping the exact Kubernetes objects as the configuration that later systems review and deliver. The source stays recorded, but its processor does not run again in the delivery path. Flat objects can be read, compared, scanned, changed one field at a time, stored as OCI, or held as ConfigHub Units. It is not safe to assume every chart can be flattened without more work.

Two delivery models coexist. The catalog packages charts render-late: the installer package carries the un-rendered chart, and the toolchain renders at install time. The eks-inference example renders early: CI flattens charts to literal YAML, publishes OCI bundles, and delivery never runs Helm. Neither wins as a doctrine. The catalog machinery certifies, the flattened-bundle shape delivers wherever certification allows, and the flattening-safety verdict arbitrates. Render-late stays the certified route for charts the verdict rejects, chosen by receipt rather than by taste.

The four verdicts

A verdict is decided per base, not per chart. The same chart with auth.existingSecret set is a different question from the same chart without it, and the recorded scope says which values move the answer.

How the audited bases fall today

Of 257 retained bases, 245 have a decided verdict. 97 of those refuse a flattened bundle and stay render-late through their installer package; 75 can be flattened only when named companion routes travel with the bundle.

• safe-to-flatten: 70 bases.
• flatten-with-routes: 75 bases.
• unsafe-to-flatten: 97 bases.
• born-flattened: 3 bases.
• not assessed yet: 12 bases.

Two plain examples of what a flattened render would lose:

• A chart that reads a cluster value with Helm lookup has no answer until install time. Flattened, it bakes in whatever the lookup returned when the render ran, or nothing, so the objects are stale or empty.
• A chart that generates a password in a hook produces a fresh secret each install. Flattened, that generation step is gone, so the rendered Secret carries one fixed value instead.

A base's verdict is one chart at a time. A stack's flattened release is a second judgement on top. It holds only when every part's verdict permits flattening, so one unsafe-to-flatten part keeps that part render-late even inside an otherwise flattened stack.

One shape, from source to a synced digest

A source whose verdict permits flattening — safe-to-flatten, flatten-with-routes, or born-flattened — flows through one shape, whether it is a Helm chart, a Kubara-generated tree, an AICR recipe, or raw YAML.

1. Render or flatten once, with declared inputs, at build time and never in the delivery path.
2. Package as a certified bundle: one OCI artifact per component, a digest-bound index pinning the composition, and a receipt.
3. Ingest as Units at per-file granularity, with the bundle digest recorded, into a base Space no target deploys.
4. Vary per target, then publish governed releases against an immutable digest.
5. Any reconciler syncs that digest: Argo per cluster, Sveltos across a labeled fleet, plain kubectl for the minimal path.
6. Receipts close the loop where convergence is recorded.

An unsafe-to-flatten source skips this build-time pipeline. Its processor runs late, at install time, through its installer package, which stays its certified route.

The receipt certifies rendering and packaging, not runtime health, and convergence receipts stay separate. A decided lane does not mean a bundle exists or ever will. Publication is a separate step, gated on the lane permitting it, and an unsafe-to-flatten entry must never carry a certified-bundle receipt.

The rules are in when to flatten configuration, deciding a flattening lane, and the certified bundle spec. The certified bundles record lists the flattened ones so far.

4. 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.

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, with 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.

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 template locally, 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 installer pulls a catalog package that already ships an image; it cannot pull a chart that has none.
• Manage it in ConfigHub. cub helm install records 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.