1. Check the starting point
The application needs a reviewed configuration, any environment changes, and a target or delivery path. If those choices are still open, start with the Component Catalog, Variants, or Apps.
2. Choose an operation
Status legend
available runs today. watch has evidence plus a named limitation. Planned work still needs a product, policy, support, or service decision.
A green GitOps sync tells you the controller accepted the manifest, which is a smaller claim than a working application. Where the claim depends on live state, use observation receipts.
Diff before you ship
availableA variant is one named configuration of an app. Its object diff shows exactly which Kubernetes objects changed before anything is delivered. This is the opposite of a values file you have to mentally render.
Scan and gate
availableRun scans over the rendered objects for privilege, exposure and deprecated APIs. A gate is a release stop, so delivery waits until each finding is accepted or waived with a named reason.
Release a prepared variant
watchNew 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.
cub variant promote <space> --dry-run -o mutations
cub variant promote <space>Apps and Variants choose the base, derived variant, and target. We've proven this on Redis, NGINX, and kube-prometheus-stack: previewing the change, updating objects that changed, and adding new ones.
Deliver via OCI + GitOps
availablePublish the variant as an OCI artifact, which is a digest-pinned delivery bundle that Argo or Flux pulls and reconciles. A green local apply and a reconciled controller are different events, so both are recorded separately.
See: How tests support each claim · GitOps test results · Argo CD and Flux guide
Observe the live result
availablecub-scout receipt verify \
--file <rendered-objects.yaml> \
--scope namespace/<namespace> \
--predicate object-set-matches \
--ttl 1h \
--out .tmp/object-set.receipt.json
cub-scout receipt validate .tmp/object-set.receipt.jsonAfter delivery, check what actually happened. The receipt names the check, time, namespace or target, and whether the cluster matched the desired objects.
See: Check it yourself · Why a sync check is not enough · What each path can prove
Rehearse rollback before you need it
watchcub unit diff <unit> --from=PreviousLiveRevisionNum --to=LiveRevisionNum
cub-scout compare three-way --dry-from <previous-render.yaml>You see the difference between the current live app and the previous approved state. Today this is a rehearse-and-review path, because exact rollback automation depends on the app, the target, and any lifecycle step that cannot be undone.
See: The day-2 upgrade story · Upgrade and rollback guide · Three-way comparison design
3. Keep a fleet record
The fleet use case begins when a platform team needs to know what many clusters should run and whether each cluster matches that record.
Use one visible sequence: choose the approved configuration, select targets by label, and preview the exact target list.
Publish to a small wave, then inspect every target before continuing. The Sveltos example records two waves. Managed pause and resume controls are still planned.
A useful record says: this cluster, customer, or environment should run this package release, this preset, these allowed inputs, this target, and these approval gates. The package fixes most choices ahead of time. Only a small, restricted set of settings remains at install time, so an upgrade does not become another free-form Helm exercise.
| Fleet area | Who usually owns it | What ConfigHub records |
|---|---|---|
| User workloads | Application teams | The approved app variant, target, inputs, policy gates, and release history. |
| System services | Platform operators | Shared services such as DNS, monitoring, ingress, and storage, with controlled upgrades across clusters. |
| System configuration | Cluster or fleet systems | Opt-in platform components such as GPU, network, security, and operator configuration, reconciled from a signed-off package and fleet record. |
Read the three checked examples for their owners, targets, checks, rollout order, and current evidence. They cover NGINX, Kube Prometheus Stack, and a Kubara platform configuration.
This is why the site keeps package OCI separate from delivery OCI. See every OCI shape and who consumes each one.
4. Govern with the commercial product when needed
When the work carries private inputs, production responsibility, multiple teams, policy, SLA, or fleet scale, the Upgrade guide describes what the commercial product governs.
5. Build a ConfigHub App
An App performs one repeated job, such as reviewing an upgrade, checking RBAC, or rolling a platform change across clusters. It reads the exact Kubernetes objects and proposes a change, runs the checks, waits for approval, then publishes a release and records what happened. AI can help along the way, while the reviewed objects and the policy result decide what ships.
Everything here works once the configuration is saved in ConfigHub, which needs a free account. If it is not saved yet, start from an example, or follow Apps on a platform to record an application that already runs. The official tutorial shows the shortest path from one component to a promoted variant.
What the App operates
An application is the set of Kubernetes objects your team operates together. That might be one chart, several charts, or your own files, and it can be imported from a system you already run.
| Kind | Meaning |
|---|---|
| One public chart | A catalog chart such as Redis, Prometheus, ingress-nginx, or cert-manager that you want to install and keep updated. |
| Several charts | A group of charts that must be released together, such as an application, database, cache, and monitoring. |
| Platform services | Shared services such as ingress, certificates, policy, monitoring, logging, or identity. |
| Your own Kubernetes files | Deployments, Services, ConfigMaps, Secrets, policies, and other objects written by your team. |
| An imported application | An application first found in Argo, Flux, rendered YAML, a Helm release, or a live cluster, then saved in ConfigHub. |
The normal order
Start from the saved objects and show the proposed change. Run the required checks, publish the approved release, then check what happened on the cluster.
Choose saved configuration
Select the component, base, and environment variant that the App will operate.
Show the proposed change
Turn the request into exact Kubernetes object changes that a reviewer can read.
Run the checks
Scan the changed objects, stopping wherever a required check or approval is still missing.
Publish the release
Create the approved OCI release for Argo CD, Flux, or another delivery path.
Check the result
Compare the desired objects with what the cluster reports and record the outcome.
Common uses
| Example | What ConfigHub helps with |
|---|---|
| Redis app | One public chart can be rendered from a base variant, checked, changed for each environment, and released again. |
| Prometheus or kube-prometheus-stack | A chart with CRDs, webhooks, and prerequisites can use base variants that say what the target must provide before release. |
| Platform services | Ingress, certificates, policy, monitoring, and logging can be grouped with the application that depends on them. |
| Your service plus chart services | Your own service can sit beside a database, queue, cache, or monitoring chart. |
| Existing app | An application already in a cluster can be inventoried first, then brought under review when you are ready. |
| AI-suggested change | AI can propose a values change or file edit. ConfigHub shows the exact diff and checks before it is approved. |
The Redis upgrade and rollback proof follows one complete run from chart 25.5.3 to 27.0.0 and back. A two-replica edit stays in place while the candidate moves through development and staging. Two Argo CD clusters run the candidate and rollback OCI releases.
The RBAC review proof starts with a service account that can read Secrets unnecessarily. It records one precise correction in ConfigHub, requires approval, publishes the approved objects as OCI, and lets Argo CD deliver them to an isolated cluster. Secret access is gone while ConfigMap access still works.
Component and chart evidence still lives in the Component Catalog. This page explains how those components become part of applications your team runs.
6. Open the working App demonstrations
Each row has one checked example with committed evidence. The final column says what is still needed before the same result can be offered more generally.
| App | What ran | Broader status | Still to build |
|---|---|---|---|
| Upgrade App | Redis upgrades from chart 25.5.3 to 27.0.0 without losing a post-render replica change, moves through development and staging, reaches two Argo CD clusters, and rolls back. | partial | This is a guarded demonstration and receipt, not a finished ConfigHub App interface. |
| Hooks and CRDs App | Kube Prometheus Stack passes the recorded CRD, certificate, workload, webhook, and runtime sequence on fresh installs and on an 85.3.3 to 86.1.0 upgrade through Argo CD and Flux. | partial | ConfigHub does not yet select and execute the chart-specific route automatically. |
| RBAC Review App | One review removes unnecessary Secret access, keeps ConfigMap access, requires approval, publishes OCI, and reaches Kubernetes through Argo CD. | partial | The example does not yet build a complete RBAC binding graph across a live fleet. |
| Fleet Platform App | Kubara proves one platform target, while Sveltos proves a pilot and two-cluster expansion with separate reviewed OCI digests and drift recovery. | partial | A large mixed-source fleet rollout with failure-based pausing remains open. |
| AI Change Review App | The example finds an unpinned image and inline API key, clears the reviewed replacement, and proves that approval controls the ConfigHub apply dry-run. | partial | Kubernetes delivery, promotion, rollback, GPU workload health, and live observation have not run for this candidate. |
Open the demonstration programme for the steps, evidence, and current limit for every App.