UNOFFICIAL/EXPERIMENTAL. The whole system is four moves - render → route → deliver → observe - plus how you customize, promote, and operate over time. This page is the map; each link goes deeper.
The mental model
- Render - turn a chart into the exact Kubernetes objects (the recipe).
- Route - everything that is not in the recipe (hooks, CRD installs, target facts,
lookup(), …) becomes an explicit, named step - never silently run. - Deliver - publish the recipe once to OCI; Argo, Flux, or plain
kubectlall pull the same bundle. - Observe - prove it live with receipts; report an honest disposition, never "just green."
_New to the vocabulary (Unit, space, target, OCI bundle)? Start with the data model._
The reason for the model is simpler than the vocabulary. Helm remains the chart source. The catalog turns common chart shapes into vetted package releases, with most choices fixed before install and only a small, documented input surface left open. ConfigHub then becomes the source of record for which package, preset, allowed inputs, and target each app, cluster, customer, or environment should run.
1. Render - the recipe
cub installer renders a chart base into the same objects helm template produces, proven object-for-object by render parity. → direct-cub-helm-model · reading-the-matrix · chain-of-proof
2. Route - everything not in the recipe
Hooks, CRD installs, target facts, lookups - anything that does not survive a config-only render is a routed quirk: visible, named, receipted, and never silently executed. The standing rules are in the doctrine. → chart-hooks-what-happens · pathway-route-hooks-transparently · change-routing-before-oci · hook-lifecycle-strategy · target-prerequisites
3. Deliver - one OCI bundle, your choice of controller
ConfigHub publishes the Units once as an OCI artifact; Argo (Application), Flux (OCIRepository), or cub/kubectl all pull the same bytes. Proven - one bundle, three consumers, the routed hook ran under each (receipt). Includes the credentials story (OCI pull creds vs app secrets). → cub-deployment-path · gitops-adopter-guide
This is where the story stops being an installer story. Bootstrap commands can be imperative, but day-2 upgrades should come from the recorded desired state: package release, preset, allowed inputs, target, approvals, and delivery receipt. The controller reconciles that record instead of asking every operator or agent to rerun a sequence from memory.
4. Observe - receipts, honest disposition
Live proof, lane by lane; watch ≠ pass; render parity ≠ live-ready; we say what we refuse to claim. The full testing model is the test map. → verification-lanes · outcomes-and-tests · what-we-refuse-to-claim · live-parity · why-synced-is-not-working
Customize + promote (variants)
Base variants vs derived ConfigHub variants, overlays, and promotion across environments. → creating-variants · derived-variant-walkthrough · custom-overlays · extension-slots · cub-variant-command-surface
Day-1 - preview, dry-run, drift
See desired-vs-live before you apply; understand why "synced" isn't "working." → cub-scout-diff-design · reverse-reconcile-design · why-synced-is-not-working
Day-2 - upgrade, rollback, maintenance
How an opaque Helm upgrade becomes staged, reviewed, rehearsed, and observed; refresh and support over time. → day2-upgrade-rollback · helm-upgrade-crash-example · remote-images-and-supported-bases · maintenance-sla
Security - secrets, credentials, RBAC, scanning
The one "no silent privileged step" story: delivery creds (OCI pull, copied not printed), your app's Secrets (generated vs existing vs staged target fact), RBAC visible in the recipe, and scanning + the adversarial lanes. → security-end-to-end · cub-deployment-path · target-prerequisites
Why this exists / why it holds
The Generative GitOps thesis, the Helm pain points it answers, and why it doesn't collapse under hooks/quirks/volume. → why-this-exists · generative-gitops-fit · why-this-does-not-collapse · helm-pain-points
Free vs managed
What's public and free to try, and where ConfigHub Server / managed workflows begin. → offering · what-you-get · product-support-tiers
Get started
→ choose-your-path · choosing-commands · first-run-walkthrough · try-now · tutorial-sequence