Inspect and keep an exact record
Download record.json with the full Redis default record and its Catalog and record hashes. No setup needed. The linked draft exercise reproduces the lookup and a refusal locally with Node and a checkout.
Choose the question closest to your current work. Each link opens the commands, example, or evidence you need.
Use these guides for the commands behind every supported input format, and for ConfigHub.
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.
Local Guides and inspection
Finish with files you can inspect and keep. The walkthroughs include setup, direct commands, an assistant task, expected results and a failure case. Start with the job you need; no ConfigHub account or cluster is needed.
Inspect and keep an exact record
Download record.json with the full Redis default record and its Catalog and record hashes. No setup needed. The linked draft exercise reproduces the lookup and a refusal locally with Node and a checkout.
Walk the ten questions a Helm user asks, with the pain beneath each one and a check you run on your agent's answer.
Compose a platform with an app
Save a Kubara and Argo CD selection, move it, edit the app and retain a refusal when an API does not fit.
Adapt a configuration and review the edit
Change one replica count, inspect the exact diff and spot an unexpected second edit.
Match a GPU workload to supplied facts
Keep candidate, mismatch and unknown results separately, with the input hashes behind each answer.
Find why a Helm value did nothing
Compare a typo with the correct key in controlled renders, including a value the template transforms.
Add a field and preserve the source
Review one added label, detect an object replacement and restore the exact original file.
Compare retained versions and prepare a review packet that keeps missing promotion evidence visible.
Inspect a hook without running it, preserve an API refusal and identify what delivery still requires.
Answer the questions Timoni users ask
Build a typed module's exact objects, check the typed schema and the CRD ordering, and see which module bytes are digest-bound.
Assistants run the same commands. Inspection uses the repository adapter; the cub Guides use the Workshop plugin. Actual live-chat API integration remains a separate route.
Three guides, shortest first. Each one runs real commands against real packages, so you finish with output you can check.
The object digest, the OCI manifest digest, and the release digest are three different records. See the digest glossary.
Run the short example: pull one public package, render it locally, and read the exact Kubernetes objects it produces, all on your machine. Work through an example like yours: start from your own Helm values, an AICR recipe, an OCI package, or Kubernetes YAML. Follow one package end to end: take a single Redis configuration through pulling, verifying, changing, and upgrading it.
The same questions apply to every input format, from a Helm chart to plain Kubernetes YAML. Choose the question you need before choosing a command.
| Question | What you need | What it does not prove |
|---|---|---|
| What do I have? | The source, snapshot, package, or exact files. | What a source tool will generate, or whether a destination can run it. |
| What will it produce? | The source inputs and the exact materialization command, or literal objects where materialization is a no-op. | Whether a named destination has the required APIs, credentials, hardware, and lifecycle setup. |
| Can this destination accept it? | The exact candidate and current facts from the named destination. | That the configuration has been deployed or works at runtime. |
| Did it work? | The exact delivered revision and the live result required by the claim. | Results for another revision, destination, or untested behavior. |
A missing prerequisite marks the unanswered stage blocked or not run, which is a gap in coverage rather than a failure of the source or its result.
Try Redis for a short local exercise with no server, cluster, or account.
Pull and verify the seven-Application CPU starter, then write it as a local OCI without ConfigHub or Kubernetes.
Use the Component Catalog to choose a component and exact retained package version, then inspect its packaged configurations, required setup, and evidence.
Worked Examples covers your own Helm values, an AICR recipe, or plain Kubernetes YAML.
See what cub helm template, cub helm install, cub installer, and the ConfigHub upload and variant commands each prove.
Read the cheat sheet from Helm habits such as --set and release names to cub's declared-input model.
Pull a catalog package, render it locally, and keep the files under your own control with no server, account, or cluster.
Build a local prompt for the AI assistant you already use. Private charts and values stay on your machine.
Keep Kubara's component selection and generated topology, with Argo reconciliation intact, while following one six-step adoption tutorial with explicit evidence checkpoints.
Deployment explains the local files, OCI, and ConfigHub choices in one sequence.
Choose the local OCI or ConfigHub release path, then let Argo CD or Flux pull the reviewed objects.
See how required setup is recorded and ordered, then tested or marked blocked.
Use this guide to decide whether a change belongs in Helm values or in the stored Kubernetes objects.
The GitOps guide explains how controllers pull reviewed Kubernetes objects from Git or OCI.
Create, compare, and promote development and production variants.
Compare the exact current result with the candidate for the next stage. The review shows what changed, what blocks the move, and what still needs a staging test.
The day-2 upgrade story: diff the value model first, check control points and immutable fields, then upgrade rendered bundles by digest. The Redis walkthrough shows one full upgrade, promotion, and rollback.
Apps on ConfigHub includes upgrade, RBAC, and fleet examples, among others.
Open the Kubara and Sveltos examples for platform configuration, cluster assignments, and rollout evidence.
Start read-only from GitOps, Helm, or a live cluster.
Repoint image references across environments with the digest intact, promote the change environment by environment, and prove where it landed.
Install the released check plugin, run cub check locally, and keep its JSON result with the exact files and digest. No ConfigHub account or server is required.
Find the command that checks generated Kubernetes files, a saved test record, or a live cluster.
See which fields the current drift check covers and which differences it can still miss.
Read the named limitations and the evidence behind them.
Separate source, render, setup, target, and runtime failures.
Turn a checked result into a bounded Markdown or JSON report, then post it in GitHub, GitLab, Jenkins, or another review system.
The FAQ answers questions about safety, upgrades, and current limits, among others.
Every guide, reference, and demonstration record on the site, grouped by area. Browse all technical references for the curated set.
How a source becomes reviewed objects, how their identities stay apart, and how a reviewed variant is changed, promoted, and delivered now live on one page. Follow a configuration from source to running, or read the record in the model and vocabulary guide.
Choose what you want to do next and open the matching page.
New to ConfigHub? Follow the official ConfigHub tutorial. It covers one component, a release, a change, production, and promotion. This site provides the public catalog and its evidence.
| Task | Open | Why |
|---|---|---|
| Learn ConfigHub | Official tutorial | Set up a cluster. Install and release one component. Change it, add production, and promote the change. |
| Try Redis without an account | Try Redis | Render one reviewed Redis configuration. Inspect the files and local OCI without ConfigHub Server. |
| Try AICR without an account | Try AICR | Pull one public AICR configuration, reproduce the seven-Application CPU starter, verify every file, and write a local OCI without a cluster or GPU. |
| Follow the complete Redis example | Detailed Redis walkthrough | Add Helm parity, Kubernetes, a major upgrade, promotion, two-cluster delivery, and rollback. |
| Check or promote your own config | Check my config | Compare exact objects in your browser, carry Catalog lifecycle facts into the review, then continue to a source-aware promotion plan. |
| Use your AI agent | AI agents | Install the ConfigHub Workshop skill, choose one task, and keep source records, exact objects, lifecycle work, checks, and limits visible. |
| Choose a worked example | Examples | Start with Helm, AICR, OCI, or YAML. Continue with ConfigHub only when you want saved configuration and managed operations. |
| Start or adopt a Kubara platform | Kubara with ConfigHub | Generate one small native Kubara development platform, or bring an existing platform through Git and OCI. Keep Kubara as composer and Argo CD as reconciler. |
| Follow configuration to deployment | Operate | Release a reviewed configuration by digest, promote it, gate it on approval, and roll it back. |
| See every source and App demonstration | Demonstration record | See the exact example that ran, its result, and the work still needed for broader support. |
| Choose a public component | Component Catalog | Pick an exact retained package version, then read its packaged configurations, output, hooks, CRDs, setup work, and evidence. |
| Run ConfigHub yourself | ConfigHub | The sandbox server runs the same examples locally in about twenty seconds. |
| Use an App on ConfigHub | Apps | Use saved configuration for upgrade review, hooks and CRDs, RBAC review, fleet rollout, or AI change review. |
| Check a claim | Check one claim | Choose the command that answers your question and see whether it uses saved evidence or a fresh run. |
| Read the limits | FAQ | Hooks, CRDs, upgrades, generated secrets, AI changes, rollback, and current gaps. |
| Know when managed help begins | Upgrade | Private sources, production support, teams, policies, fleet operations, and commercial boundaries. |
Start from the public chart page. Do not start from a generated package folder unless you already know what you are looking for.
| Step | Open | What you learn |
|---|---|---|
| 1 | Chart page | Which base variants are supported and what still needs work. |
| 2 | Full rendered YAML | The Kubernetes objects captured from one base variant. This is the output of the render. |
| 3 | Render intent | The Helm chart version, values, namespace, release name, capability profile, source lock, output path, and evidence links. |
| 4 | Hooks, CRDs, and setup work | The route decisions for chart behavior that is not just static YAML. |
| 5 | Check one claim | The commands and receipts that back a claim. |
These words have specific jobs. Using them consistently makes the instructions and evidence easier to follow.
| Word | Meaning |
|---|---|
| Render | Create Kubernetes objects from a recorded source and its inputs. |
| Materialize | Produce or read the exact objects a source yields: Helm renders, Timoni builds, AICR and Kubara generate; literal YAML and OCI are read as they are. |
| Flatten | Keep those exact objects as the configuration you review and deliver, so the source processor does not run again in the delivery path. |
| Inspect | Read the objects or evidence. |
| Test | Run a defined command or procedure. |
| Verify | Compare a result with a recorded expectation, digest, or object set. |
| Review | Decide whether a known change or result is acceptable. |
| Prove | Produce an inspectable receipt for one scoped claim. |
The model and vocabulary guide defines base variants, render intents, Units, Spaces, routes, and receipts.
If you are an AI agent or maintainer changing helm-expt, use the repo notes instead of the public site. They list repo commands, recovery steps, verification commands, catalog read-only rules, and the human/agent docs rule.
The Examples page explains what to run. Use this table when you need the source, stored record, or published package behind an example.
| Place | What belongs there |
|---|---|
| This website | Short explanations, worked examples, chart pages, and links to current proof. |
| GitHub | Source configuration, generators, scripts, checks, receipts, and every file used to make the website. |
| The ConfigHub helm-catalog organization | Persistent demo Spaces. Each Space has one README Unit that explains its purpose and the Units it contains. Open demo-org guide. |
| Public OCI registry | Stable starting packages and reviewed public outputs. Each permanent artifact has a role, digest, source record, guide, and publication receipt. |
| ConfigHub release OCI | Approved outputs from managed Spaces for Argo CD, Flux, or another recorded delivery path. |
| Temporary proof registry | Short-lived artifacts used by one receipt. The site does not advertise them as permanent packages. |
Most users start by previewing a chart. Add more when you need to save the inputs, share versions with a team, review changes, hand off to GitOps, or run releases.
| Stage | What you do | Command or page | Needs ConfigHub? |
|---|---|---|---|
| 1. Choose | Start with Helm, AICR, existing OCI, or Kubernetes YAML. | Examples | No |
| 2. Inspect | Create exact Kubernetes objects and read them before delivery. | Try Redis | No |
| 3. Record | Store one reviewed configuration and release it. | Official tutorial | Yes |
| 4. Change | Add development and production configurations. | Official tutorial | Yes |
| 5. Promote | Move a reviewed change from its base through development and production. | Official tutorial | Yes |
Use these when you need the next level of detail after the main pages.
| Guide | What it helps with | Open |
|---|---|---|
| Official ConfigHub tutorial | Set up a cluster, install and release one component, make a change, add production, and promote the change. | Official ConfigHub tutorial |
| Examples | Choose a starting input, then see working promotion, delivery, platform, policy, and App examples. | Examples |
| Worked examples | Commands and proof links for Helm, AICR, existing OCI, and Kubernetes YAML. | Worked examples |
| Operate | Release a reviewed configuration by digest, promote it, gate it on approval, and roll it back. | Operate |
| Config catalog demonstrations | The maintained paths for Helm, AICR, cub installer, public OCI work, Kubara, and Sveltos, followed by variants, promotions, policy, and five ConfigHub Apps. | Config catalog demonstrations |
| Config catalog doctrine | The anonymous-to-managed boundary, four OCI package roles, base variants, fleet delivery, policy rules, and AI maintenance rules. | Config catalog doctrine |
| When to flatten configuration | Choose exact objects, exact objects with recorded setup, or late source processing for one source, configuration, and target. | When to flatten configuration |
| Check and promote with AI | Use the browser-local Check and Promote records with your own assistant, source-aware field attribution, exact target results, and an optional ConfigHub handoff. | Check and promote with AI |
| Anonymous browser check | Inspect rendered YAML, compare exact objects, run static checks, and download one complete result for your own AI or CI without signing in. | Anonymous browser check |
| Anonymous OCI work in CI | A GitHub Actions run with no ConfigHub credentials pulls a public package, renders and checks its objects, creates an OCI layout, and pulls the same objects back. | Anonymous OCI work in CI |
| Anonymous OCI change | Pull five public NGINX objects without credentials, change only the replica count, store the source and check records, and pull the new local OCI back for comparison. | Anonymous OCI change |
| Redis public walkthrough | Pull Redis 25.5.3 and 27.0.0 anonymously, retain the selected existing-Secret base, keep Secrets out of both object sets, and verify both local OCI outputs by pulling them back. | Redis public walkthrough |
| OCI import, promotion, and two-cluster rollout | One live run imports exact Kubernetes objects from OCI, promotes a change through development and staging, exports one deployable OCI, and records exact-object and convergence receipts on two Argo CD clusters. | OCI import, promotion, and two-cluster rollout |
| Redis upgrade, promotion, and rollback | A live chart upgrade keeps a post-render replica change, moves through development and staging, reaches two Argo CD clusters, then restores the exact pre-upgrade revisions and checks both clusters again. | Redis upgrade, promotion, and rollback |
| AICR EKS H100 example | AICR selects and orders a GPU platform. Two public OCI artifacts carry the source package and 17 exact Argo CD Applications. ConfigHub stores the Applications as a base, changes one Grafana Secret reference in development, and promotes that result to staging. | AICR EKS H100 example |
| AICR anonymous CPU starter | Pull the retained AICR configuration without credentials, select and hash-check seven Applications, then write and verify a local OCI without contacting ConfigHub or Kubernetes. | AICR anonymous CPU starter |
| AICR OCI round trip | A live OCI-to-ConfigHub-to-OCI test imports 17 AICR-generated Argo CD Applications, publishes a ConfigHub release, pulls it back, and compares every object without claiming a GPU rollout. | AICR OCI round trip |
| AI change review proof | ConfigHub reports a mutable nested AICR image, blocks an inline API key, clears the reviewed candidate, requires approval, and leaves ordinary Deployment checks off the custom resource. | AI change review proof |
| Gated answer: what will this install | An assistant answers the most common question from a metrics-server render, and a gate holds the answer to the exact objects and prerequisites so it cannot invent or omit one. | Gated answer: what will this install |
| Gated answer: candidate versus production | An assistant diffs two Redis releases, and a gate holds the answer to the exact object diff, one removed Secret and two changed StatefulSets. | Gated answer: candidate versus production |
| Check supplied values against a retained render | Check whether supplied Redis value literals appear in one retained render. Presence or absence alone does not prove whether the chart used a values key. | Check supplied values against a retained render |
| Gated answer: upgrade risk | An assistant judges a Redis 25 to 27 upgrade by removed, immutable, and image changes, and the gate holds the verdict to what the two renders show. | Gated answer: upgrade risk |
| Review to promotion handoff | A check reads the live promotion receipt and confirms the governed Redis promotion carried the same reviewed bytes through development and staging in order. | Review to promotion handoff |
| Gated answer: hooks and CRDs | An assistant lists the Kube Prometheus Stack CRDs, the custom resources that need them first, and the admission webhooks that need a caBundle, and a gate holds each claim to the render. | Gated answer: hooks and CRDs |
| Gated answer: where a fleet image runs | An assistant places a Redis image-digest change across four environments, and a gate holds it to the fleet matrix, including the one environment an override shields. | Gated answer: where a fleet image runs |
| Gated answer: must I fork for a missing field | An assistant proposes the smallest post-render edit instead of a fork, and a gate confirms the edit targets a real Redis object and adds a field the render does not already carry. | Gated answer: must I fork for a missing field |
| Gated answer: roll back to exact revisions | A check reads the live rollback receipt and confirms a retained change set restored 14 Redis units to their exact pre-upgrade revisions, back to the prior chart version. | Gated answer: roll back to exact revisions |
| Gated answer: same version, same bytes | An assistant compares a recipe's locked digest against the digest a publisher later served for the same version, and a gate holds the same-bytes verdict to the upstream-drift record. | Gated answer: same version, same bytes |
| RBAC review example | Find unnecessary Secret access, make one exact Role change, require approval, publish the reviewed objects as OCI, and let Argo CD deliver the result. | RBAC review example |
| RBAC permissions report | Review broad RBAC rules across committed default chart renders without needing a cluster or running Helm again. | RBAC permissions report |
| Kubara with ConfigHub | The buyer landing page: what stays Kubara, what ConfigHub adds, the six adoption steps, measured benefits, current proof status, GUI tour, and honest boundaries. | Kubara with ConfigHub |
| Kubara six-step adoption tutorial | Choose components, generate with Kubara, push the complete Git hand-off, create immutable OCI, load the selected ConfigHub organization, and deploy applications through Argo CD. | Kubara six-step adoption tutorial |
| Kubara + ConfigHub technical mini-IDP | The complete maintainer-grade v0.13.0 runbook: four clusters, seven platform roles, two apps, exact catalog generation, Git/OCI import, matrix, wiring, faithful hub-spoke delivery, and receipt-gated ConfigHub platform surfaces. | Kubara + ConfigHub technical mini-IDP |
| Historical Kubara v0.12.0 compatibility proof | Retained read-only evidence for the one-cluster generation, OCI route, Argo bootstrap, and dated live result. It is not a command path for the current Kubara organization. | Historical Kubara v0.12.0 compatibility proof |
| Sveltos Kyverno fleet example | A two-wave result: ConfigHub approves a pilot and one selector expansion at different OCI digests, then Argo CD and Sveltos deliver Kyverno to one staging cluster and later to both. | Sveltos Kyverno fleet example |
| Hooks and CRDs example | Kube Prometheus Stack install order, eight checked route records, Argo CD and Flux choices, live evidence, and what remains manual. | Hooks and CRDs example |
| Try Redis | Render and inspect one reviewed Redis configuration without ConfigHub Server or a ConfigHub account. | Try Redis |
| Try AICR | Pull and verify one AICR-derived seven-Application configuration without a ConfigHub account, cluster, cloud account, or GPU. | Try AICR |
| Detailed Redis walkthrough | Add Helm parity, Kubernetes, OCI, a major upgrade, promotion, two-cluster delivery, and rollback. | Detailed Redis walkthrough |
| Check one claim | Choose one project check, see what it proves, and learn whether it needs a cluster. | Check one claim |
| AI agents | Install the ConfigHub Workshop skill for known Catalog questions, your own configuration, promotion review, and cross-format source inspection. | AI agents |
| Choose a component | Browse component pages, retained versions, packaged configurations, known risks, and first-use advice. | Choose a component |
| Live ConfigHub example guides | README pages for live demo Spaces. Each guide says why the Space exists and what to inspect first. | Live ConfigHub example guides |
| Installer package OCI refs | The package refs users pull with cub installer setup --pull oci://..., and how they differ from ConfigHub delivery OCI. | Installer package OCI refs |
| Inspect an OCI package | One command that identifies the package role, resolves its digest, and reports the exact Kubernetes objects and obvious lifecycle work it contains. | Inspect an OCI package |
| Change an OCI package | Change one field in a literal Kubernetes OCI, run checks, keep its source records, and build a new local OCI without a ConfigHub account. | Change an OCI package |
| Helm base variants and values | Why the catalog supports useful chart-specific base variants instead of claiming every values combination. | Helm base variants and values |
| Chart setup and lifecycle work | Find the hooks, CRDs, webhooks, generated values, storage, and RBAC a chart still needs. | Chart setup and lifecycle work |
| Create variants | When to make a new Helm-rendered base, and when to make a ConfigHub version after render. | Create variants |
| Apps | Use configuration saved in ConfigHub for upgrade review, hooks and CRDs, RBAC review, fleet rollout, and AI change review. | Apps |
| Combine charts and your service | Put public charts and services your team owns into one reviewed application release. | Combine charts and your service |
| Understand an existing app | Start read-only from Argo CD, Flux, rendered YAML, live cluster state, or a Helm release. | Understand an existing app |
| Ops | Release, observe, patch, and upgrade after the files are recorded. | Ops |
| Review security before release | Review exact objects, Secrets, checks, approvals, OCI delivery, and the limits of each result. | Review security before release |
| What is not ready yet | The honest register of what remains planned or partly tested. | What is not ready yet |
| Find a direct answer | Direct answers about hooks, upgrades, AI changes, free use, and current limits. | Find a direct answer |
| See what is not ready yet | Current limitations, their effect, and the safest action available now. | See what is not ready yet |
| Model and taxonomy | The five terms, the F1-F4 stages, and the same objects seen from plain Helm, Kustomize, and source-object viewpoints. | Model and taxonomy |
| The data model | Definitions for Space, Unit, target, route, and receipt. | The data model |
| Variants after upload | The step-by-step cub variant walkthrough: create an environment variant, preview with a dry run, then promote reviewed changes. | Variants after upload |
| App to live, end to end | A plain app into ConfigHub, staging and prod variants, OCI to Argo delivery, and a staged rollout: the whole chain, run live. | App to live, end to end |
| Image registry migration | Repoint a chart's image registry across a fleet with the digest intact, promote it environment by environment, and prove where it landed. Run live. | Image registry migration |
| Expected results and clusters | Which commands need a cluster and what output to expect. | Expected results and clusters |
| Deployment path | How a cub installer package becomes files, a ConfigHub upload, an OCI bundle, or controller input. | Deployment path |
| GitOps adopter guide | How Argo and Flux teams can keep their controller and consume one reviewed OCI bundle. | GitOps adopter guide |
| Security end to end | Secrets, credentials, scan points, and what should never be printed or copied casually. | Security end to end |
| Day-2 upgrade and rollback | How to review and rehearse an upgrade, then observe what happened. | Day-2 upgrade and rollback |
| Helm render intents | The record behind a catalog base variant: chart version, values, namespace, release name, lifecycle routes, target prerequisites, and evidence links. | Helm render intents |
| Coming from Helm | How common Helm flags map to cub inputs. | Coming from Helm |
| AI-assisted changes | Let AI suggest a change, then review exact files, diffs, checks, and approval records. | AI-assisted changes |
| Broken chart triage | Sort a failure into render, target, lifecycle, runtime, or unsupported behavior. | Broken chart triage |
| Known gaps we surface | Current watch findings and blockers before you trust a route. | Known gaps we surface |
| Per-chart cub adoption caveats | Where cub is rougher than plain Helm on first run, and how each caveat is managed. | Per-chart cub adoption caveats |
| Custom overlays | Wrapper charts, customer values, and changes that go beyond normal values files. | Custom overlays |
| Verify it yourself | Practical commands for local checks, rendered installs, parity receipts, and scout receipts. | Verify it yourself |
| Verification checks | See which checks cover rendering, ConfigHub upload, delivery, live state, or a two-cluster comparison. | Verification checks |
| Hook lifecycle strategy | How chart hooks become visible work with status and receipts. | Hook lifecycle strategy |
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.
Each chart page gives the short answer: what can I try, and what should I watch first? The matrix and generated data are for review work. They show where the chart answer came from: render inputs, test results, receipts, known gaps, and claim status.
| Evidence | What it helps with | Open |
|---|---|---|
| Catalog data | The chart and variant matrix. | Catalog data |
| Generated data index | The generated data catalog for this repository. | Generated data index |
| Status dashboard | Current aggregate status and active proof queue. | Status dashboard |
| cub adoption caveats | The 100-chart table for first-run caveats, placeholder passwords, and CRD ordering. | cub adoption caveats |
| Helm render intents | One generated render-intent object per real base variant. | Helm render intents |
| Base variant records | Source-neutral records joining literal objects, source inputs, routes, policy, evidence, and OCI handoffs. | Base variant records |
| Operational class examples | Worked examples showing who owns a user workload, shared service, or system configuration, where it runs, which checks apply, and how it rolls out. | Operational class examples |
| Apply policy profile | The common checks, approval rules for production and system configuration, scope assertions, and self-test. | Apply policy profile |
| Hooks and CRDs App | The Kube Prometheus Stack route plan, the proven hook fixture, and the live ApplyGate rejection receipt. | Hooks and CRDs App |
| Demonstration status | Current status and evidence for the source pathways and five ConfigHub App examples. | Demonstration status |
| Demo org README files | The README text for each current helm-catalog demo Space, plus the generated upload YAML. | Demo org README files |
| Installer OCI packages | One row per package ref, setup command, package path, base list, and publication status. | Installer OCI packages |
| Claims register | What is backed, partial, planned, or refused. | Claims register |
| Check one claim | Choose the right project command for one question. | Check one claim |
| See what has been tested | Compare render, ConfigHub, OCI, GitOps, and live Kubernetes test coverage. | See what has been tested |
Continue with ConfigHub when your team needs shared variants, approvals, and rollout history.