AI and agents
Give an agent a useful task and review its answer.
Starting questions
Find explanations and references by topic. For step-by-step work, choose a Guide; for a specific Catalog entry, open its documentation.
Give an agent a useful task and review its answer.
Keep your controller while introducing reviewed configuration.
Take a checked result into deployment, then manage changes.
Deploy and manage with ConfigHub · Release, promote and roll back
Understand rendered configuration, values and variants.
How the model works · Configuration as data · Variants · Hooks, CRDs and chart behavior
Learn what an app looks like and how its dependencies fit.
Inspect an AI configuration and understand its target requirements.
Try NVIDIA AICR for GPUs · Where configurations come from · NIM example
Understand the server and choose a view of stored or live configuration.
How ConfigHub works · Official GUI and other interfaces · Scout cluster view
Find what was checked and what remains unknown.
About Workshop · Offering · Technical references
Inspect and keep an exact record. Download record.json with the full Redis default record and its Catalog and record hashes. The inspection exercise reproduces the lookup and a refusal locally.
Looking for the steps to do something? Guides hold every path an agent walks with you, and find a Guide by the step you are on.
Catalog docs: the complete entry documentation index. Find chart, app and platform demonstrations, source notes and recorded limits there.
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. |
| Manage cluster add-ons with Kubara | Kubara with ConfigHub | Choose your add-ons with Kubara, see them offline in about 15 minutes, then promote and approve each change in ConfigHub. Kubara keeps composing and Argo CD keeps reconciling. |
| 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 plan steps 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 Kubara Guide, for the add-ons Kubara manages: a first result offline in about 15 minutes, the governed path from apply to hand-back, the Workshop stack view with an app, known limits, and the live evidence. | 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 plan steps, 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 steps, 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 plan. | 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, plans, 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 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.