What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.
Start Here
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 a package without an account | Try one catalog package | Render one reviewed Redis configuration. Inspect the files and local OCI without ConfigHub Server. |
| Follow the complete Redis example | Detailed Redis walkthrough | Add Helm parity, Kubernetes, a major upgrade, promotion, two-cluster delivery, and rollback. |
| Choose a worked example | Examples | Start with Helm, AICR, OCI, or YAML. Continue with ConfigHub only when you want saved configuration and managed operations. |
| Follow configuration to deployment | Deployment | See where each tool fits, where settings belong, and how a reviewed result reaches a cluster. |
| See every source and App demonstration | Demonstration record | Separate the bounded example that ran from the broader product status and its remaining work. |
| Choose a public chart | Helm Ops Catalog | Pick a ready-to-use base variant and read its values, output, hooks, CRDs, setup work, and evidence. |
| Open the demo org | Demo org | See the same examples inside Hub. Each Space has a short README and the Kubernetes YAML for that example. |
| Use an App on ConfigHub | Apps | Use saved configuration for upgrade review, hooks and CRDs, RBAC review, fleet rollout, or AI change review. |
| Verify a claim | Verification | Choose the npm command that tests the claim instead of treating every result as the same thing. |
| 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. |
How To Read Chart Evidence
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 | Verification | The commands and receipts that back a claim. |
How This Site Uses Technical Words
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. |
| 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.
Working In This Repository?
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.
Five Stages
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 one catalog package | 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 |
Technical Guides
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 |
| Detailed entry paths | Commands and proof links for Helm, AICR, existing OCI, and Kubernetes YAML. | Detailed entry paths |
| Deployment | Start with Helm, AICR, OCI, or YAML, then inspect, manage, promote, and deploy the reviewed result. | Deployment |
| 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 |
| 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 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 |
| 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 local platform example | A real Kubara v0.12.0 generation, 77 rendered Argo CD bootstrap objects, lifecycle requirements, OCI layout, and current limits. | Kubara local platform example |
| 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 one catalog package | Render and inspect one reviewed Redis configuration without ConfigHub Server or a ConfigHub account. | Try one catalog package |
| Detailed Redis walkthrough | Add Helm parity, Kubernetes, OCI, a major upgrade, promotion, two-cluster delivery, and rollback. | Detailed Redis walkthrough |
| Verification | A landing page for npm checks, fresh live tests, committed receipts, and what each one proves. | Verification |
| AI and the catalog | How AI helps build and test the catalog, and why tests and receipts decide what is true. | AI and the catalog |
| Choose a chart | Browse public chart pages, ready-to-use base variants, known risks, and first-use advice. | Choose a chart |
| Demo org examples | The README pages for live Hub demo Spaces. Each one says why the Space exists, what problem it shows, and what to inspect first. | Demo org examples |
| 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 |
| Helm quirks | A practical list of chart behavior that needs care: hooks, CRDs, webhooks, generated values, storage, and RBAC. | Helm quirks |
| 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 |
| Application examples | Examples that combine public charts with private application pieces. | Application examples |
| Existing Apps | Start read-only from Argo, Flux, rendered YAML, live cluster state, or a Helm release. | Existing Apps |
| Ops | Release, observe, patch, and upgrade after the files are recorded. | Ops |
| Security and provenance | Secrets, credentials, scans, OCI delivery, and the limits of the current evidence. | Security and provenance |
| Future and managed ideas | What exists now, what is roadmap, and what belongs in a managed service. | Future and managed ideas |
| Answer hard questions | Direct answers about hooks, upgrades, AI changes, limits, and refusals. | Answer hard questions |
| Known Gaps | The known problems this project names instead of hiding. | Known Gaps |
| 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 lanes | Which proof lane checks render, ConfigHub upload, delivery, live state, or two-cluster parity. | Verification lanes |
| Hook lifecycle strategy | How chart hooks become visible work with status and receipts. | Hook lifecycle strategy |
Verification And Evidence
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.
| Surface | What it helps with | Open |
|---|---|---|
| Helm Ops Catalog database | The chart and variant matrix. | Helm Ops Catalog database |
| 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 |
| Verification landing page | Choose the right npm proof command. | Verification landing page |
| Deep proof page | Detailed proof lanes for reviewers who want the full evidence trail. | Deep proof page |