Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this demo org page.
Start With The README In Each Space
Every maintained example Space in the live helm-catalog org has one README. It explains why the Space exists and which problem it demonstrates. It also tells you what to open, what the example proves, and where to find supporting evidence.
Open hub.confighub.com and choose the helm-catalog org. Open a Space, then open its README.
You can also read the same pages on this website. Start with the demo org README index.
| README kind | Spaces |
|---|---|
| preset | 21 |
| environment | 11 |
| fleet | 5 |
| pilot | 1 |
| route | 2 |
| org | 2 |
| total | 47 |
Space counts as of 2026-07-30 (UTC), from the committed README data for the helm-catalog org.
What Every Maintained Example Receives
New maintained examples follow one standard. The common records make the configuration understandable and checkable; extra records are added only when that configuration needs them.
| Helper | What it answers | When it is added |
|---|---|---|
| One README | Why does this Space exist, what should I open, and what does the example prove? | Every maintained example |
| Source and intent record | Where did these objects come from, which choices produced them, what remains to be supplied, and which checks exist? | Every maintained base |
| Exact configuration objects | What would ConfigHub review, change, approve, and deliver? | Every maintained configuration Space |
| Policy profile | Which checks run before apply, and does this Space require approval? | Every managed configuration Space |
| Prerequisite and lifecycle records | Who handles Secrets, CRDs, hooks, setup jobs, controller features, or target facts? | Only when the exact configuration needs them |
The source and intent record is a document role, not one forced schema. Helm uses HelmRenderIntent. AICR uses its recipe and generation or bundle receipts. Existing OCI and plain YAML use records that name their source digest or checksums, object inventory, remaining inputs, and transformations. We do not give a non-Helm source a fake Helm record.
Today, this role may use a source Unit, Space metadata plus a committed receipt, or a generated base-variant record. ConfigHub does not yet have one first-class source object for every format.
What happens to future configurations?
Every new maintained catalog example gets the common records above. It also gets the prerequisite and lifecycle records that apply to that exact configuration.
An arbitrary upload does not gain facts that ConfigHub cannot know. Generic checks can attach automatically. The source adapter or a reviewed catalog addition must supply the source details and any chart-specific lifecycle work. Missing information remains a named gap.
Temporary experiments and legacy Spaces are not counted as conforming until their common and applicable helper records pass the same checks. Read the catalog doctrine for the full rule.
Why This Org Matters
A Helm chart is a program that produces Kubernetes objects. The templates can hide the final answer to ordinary operating questions.
- Which namespaces are missing a policy?
- Who can read Secrets?
- What changed between staging and production?
- Where does a risky setting appear across the fleet?
The demo org stores rendered Kubernetes YAML as versioned Units in a Space. ConfigHub can search, compare, review, and deliver those Units. The README explains where they came from and why the Space exists.
When you find a problem, you change the same object that you inspected. ConfigHub records that change as a revision before delivery.
What is in the org
Each base variant below is a root Space containing one supported Helm render. Its Kubernetes YAML is stored as readable Units.
Each maintained example Space has a README, rendered objects, identifying labels, and policy tests. Helm preset Spaces also have a current HelmRenderIntent Unit. Deeper examples add route, render-record, or proof Units when they are useful.
| Chart | Base variants | The story it tells |
|---|---|---|
| bitnami/redis | default, reuse-existing-secret | The version ladder: a living tree upgraded 25.5.3 to 27.0.0 through reconcile and promotion, with staging's local change preserved. |
| argo-cd/argo-cd | default, no-crds | The CRD split: the same chart with CRDs bundled or separated, side by side. |
| hashicorp/vault | dev-mode, default, ha-raft-ui | Variant diversity: three operating shapes of one chart. |
| ingress-nginx/ingress-nginx | default, internal-clusterip, admission-disabled | The admission-webhook certificate quirk, three ways. |
| prometheus-community/prometheus | default, server-only-ephemeral | The Get Started chart, as it lands in an org. |
| prometheus-community/kube-prometheus-stack | no-crds | The serious chart: eight recorded lifecycle routes in its recipe unit. |
| grafana/grafana | existing-secret-ingress, static-passwords | Secrets handled two ways. |
| bitnami/mysql | existing-secret, static-passwords | The secrets story: staged credential beside generated credential, diffable. |
| bitnami/rabbitmq | existing-secret, static-passwords | A recipe unit whose routing metadata honestly says: nothing to route. |
| bitnami/nginx | http-clusterip, existing-tls-ingress | The fleet: four environments from one base, one deliberately behind. |
The org uses ten charts so each example can include variants, promotions, and supporting evidence. The catalog pages contain evidence for all 100 charts.
Seven things to look at
Each exhibit proves one limited claim. Open the named Spaces and inspect each Unit's Revisions tab. The components view groups the Spaces by chart.
The version ladder. Open bitnami-redis-base, -staging, and -prod. Staging has a local setting of two replicas. The base moved from chart 25.5.3 to 27.0.0, then the change was promoted. The staging revision history shows both the upgrade and the retained replica setting.
The fleet. Open the four bitnami-nginx-fleet Spaces for dev, staging, prod-us, and prod-eu. One base change was promoted to all environments. Prod-eu still reports one pending upstream Unit. Dev and staging keep local replica counts while receiving the shared image change. Both production Spaces require approval.
The base also moved its NGINX image to an internal registry without changing the digest. The walkthrough and receipt show the commands and revision history. This proves the stored ConfigHub records. It does not prove Kubernetes delivery.
The secrets story. The two mysql Spaces differ in exactly one decision: a staged external credential versus a generated one. Diff any unit across the pair to see precisely what the safer choice changes.
The CRD split. The two argo-cd Spaces show the chart with and without bundled CRDs. The no-crds Space states that the cluster owns them. A live test showed that applying custom resources before their CRDs fails. Applying CRDs first and waiting for them succeeds. The Space's ProofReceipt label links to that result.
The hooks. hook-probe-base contains a Job with visible Argo CD hook annotations. The same OCI fixture ran through Argo CD, Flux, and direct apply. The hook Job completed on the cluster in all three tests. The ProofReceipt and DeliveryReceipt labels link to the evidence.
Local changes and new releases. Open hashicorp-vault-demo-base and its dev, staging, and production variants. Dev added a cost label. Staging uses two replicas, and production uses three.
The base later added telemetry and release-track annotations. Staging and production received them while keeping their replica settings. Dev had changed the same annotations map, so promotion kept the dev map and skipped the base annotations. Two recorded reconcile revisions added them afterward. The revision history shows both cases.
A staged rollout. Staging first received a real audience environment variable. The base later added the same variable as confighubplaceholder and added a shared issuer. Promotion kept staging's real value and delivered the issuer. The vet-placeholders policy prevents the placeholder from reaching a cluster.
The promotion also copied the new render-record Unit from the base into staging. The promotion receipt records the complete test.
Proposals for missing product objects. ConfigHub does not yet have separate entities for recipes, render events, render provenance, or lifecycle routes. The org represents these ideas with Units, Links, and labels. The sections below identify each proposal and its limits.
What ran live, exactly
These three examples ran on real clusters. Each receipt records the command, observations, result, and limit.
The hook delivery test. ConfigHub published one OCI bundle containing a ConfigMap and a migration Job. Argo CD, Flux, and a direct apply path pulled that same artifact on a throwaway kind cluster. Each path created the workload and completed the Job.
This test covers one routed fixture on one recorded rig. It does not cover every chart, hook type, or production environment.
The CRD ordering test. Direct apply first tried to create a custom resource before its CRD was established. Kubernetes refused the custom resource with the recorded error. Applying the CRD first and waiting for it fixed the installation. A separate receipt records the chart-specific order through Argo CD and Flux.
The Kube Prometheus Stack lifecycle test. A direct run rendered catalog package 85.3.3 and verified its chart objects. It applied ten CRDs first, ran the certificate and webhook Jobs, tested the webhook and six workloads, then removed temporary Jobs.
Separate clusters ran the Argo CD and Flux paths. Each installed the 85.3.3 no-crds OCI and upgraded to 86.1.0. Both controllers replaced the completed setup Jobs and passed the runtime tests after upgrade. ConfigHub does not yet select this route automatically.
The receipts are committed in the repo (runs/oci-hook-delivery-proof, runs/crd-ordering-gap, runs/kps-lifecycle-route-proof, and runs/kps-gitops-lifecycle-proof) and summarized under data/. Each throwaway cluster was deleted after its run.
The sketches, explained
The catalog uses four ideas that are not ConfigHub entities today. The demo org represents them with ordinary Units, Links, and labels. You can open and query these proposals, but they are not shipped product features.
| The idea | What the product has today | The sketch standing in for it | Where to look |
|---|---|---|---|
| A recipe, the DRY source of a base variant: chart, version, declared inputs, and routing intent | A plain Unit whose data happens to be recipe YAML; the server cannot tell it from a ConfigMap | The recipe unit in every chart Space | Any Space, unit recipe, data tab |
| The act of rendering: who rendered what, from which recipe, when, producing which units | Nothing. Rendering happens client-side in the installer; the server only sees the finished units arrive | A render-record unit stating chart, base, renderer, time, and output count, marked status: sketch | Space hashicorp-vault-demo-base, unit render-record |
| Render provenance: an edge from every rendered unit back to its recipe | Links exist, but they express apply-order dependencies between resources, not provenance | One exemplar rendered-from-recipe Link, from the statefulset to the recipe. One rather than thirteen because the org's Link quota is nearly spent; the render-record describes the full set | Space hashicorp-vault-demo-base, unit statefulset-vault-vault, links |
| A lifecycle route as a thing: an addressable decision about behaviour that config alone cannot carry | Rows in the repo's route data, labels on Spaces, annotations readable inside unit data. Real, but not product entities | Eight LifecycleRoute units: seven chart lifecycle routes plus one explicit CRD-first route. Each stores its class, phase, executor, alternatives, evidence, and per-delivery implementation results. | Space route-sketch-kube-prometheus-stack |
Each proposal Unit mirrors committed repo data. The top-level chart route remains automatic: false. Direct, Argo CD, Flux, and upgrade implementations have separate evidence.
The eight kube-prometheus-stack routes, one by one
A route records work that ordinary rendered objects do not perform. Five routes come from Helm hook behavior. The remaining three cover CRD order, target facts, and webhook readiness.
| Route | Quirk it routes | What it decides | Execution |
|---|---|---|---|
| crds-first | ten bundled CRDs | Apply and establish the CRDs before the chart's custom resources | target-owned |
| preflight-or-presync | pre-install and pre-upgrade hooks | Work the chart wants done before objects land runs as an explicit preflight or an Argo/Flux pre-sync step | user-executes |
| postsync-check-or-observation | post-install and post-upgrade hooks | Work the chart wants done after objects land runs as a post-sync check or a recorded observation | user-executes |
| upgrade-action-with-receipt | upgrade-time hooks | Upgrade-time actions run explicitly and leave a receipt, instead of firing invisibly mid-upgrade | user-executes |
| preserve-ordering | hook weights | Helm's numeric hook-weight ordering becomes explicit apply order or Argo sync-waves | target-owned |
| preserve-cleanup-policy | hook delete-policy | Hook resources Helm would silently delete after running are kept or removed by stated policy | target-owned |
| target-facts-or-preflight | cluster lookups, not a hook | Where the chart consults live cluster state, the answer comes from recorded target facts or an explicit preflight, not a hidden render-time lookup | user-executes |
| webhook-readiness-observation | admission webhook readiness, not a hook | The operator's admission webhook must be observed ready before dependent resources apply; an observation, not a timing gamble | target-owned |
Four routes are user-executes, and four are target-owned. Seven direct fresh-install implementations passed. Direct upgrade has not run. All eight chart-specific routes passed the recorded Argo CD and Flux install-and-upgrade path. ConfigHub does not yet select these routes automatically.
The checks are live, and honest
Every policy-covered Space has 7 common tests. Schema, placeholder, and lifecycle-route tests can stop incomplete configuration. Workloads and AICR training runtimes receive tests for the fields they use. Production releases and system configuration also require approval before apply.
| Where | Can block apply | Warns without blocking |
|---|---|---|
| Every policy-covered Space | Invalid schema; unresolved placeholder; an attached lifecycle route that lacks its required scope or evidence | An ordinary workload image without a digest; a long-running workload without declared readiness and liveness probes |
| AICR training configuration | An AI API key written directly instead of referring to a named Secret | A training image without a digest |
| Production and system configuration | All applicable checks above, plus one recorded approval | All applicable warnings above |
The lifecycle check validates a route that is present. It does not guess that a missing route means no lifecycle work exists. The source and intent record and chart review must first identify any hooks, CRDs, setup jobs, or target prerequisites.
The same policy can cover Helm, AICR, Kubara, Sveltos, or ordinary YAML after ConfigHub stores the objects.
The live org has 33 Spaces on common tests and 9 on the approval policy. The approval set contains 4 production Spaces and 5 system-configuration Spaces. These Spaces include AICR 3, cub installer 30, Helm 3, Kubara 1, rendered Kubernetes config 4, Sveltos 1. Each records its policy profile and starting format.
npm run helm-org:verify and npm run helm-org:policy:verify compare the live org with committed catalog and policy receipts.
The builder and receipts live under data/helm-org/. The org is named helm-catalog and is member-visible today. Other readers can use the committed receipts, these pages, and the walkthroughs.
Do it with your own app
You can use the same steps for your own application. Upload it, create staging and production variants, promote a change, then deliver it through OCI. Your existing GitOps controller can apply the result.
The variants walkthrough explains each command and flag. The Apps page explains how to combine your applications with catalog components.