What Counts As An Application?
An application is the set of Kubernetes objects your team operates together. It may be one chart, several charts, your own files, or something that is already running.
| 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. |
| Something already running | An application that already exists in Argo, Flux, rendered YAML, a Helm release, or a live cluster. |
Ways To Start
Start from the thing you already have. The first step is read-only: show the sources, files, objects, namespace, and owner before changing delivery.
| Entry | First move | Use it for |
|---|---|---|
| Catalog chart | Pick a chart page, choose a base variant, and render the files. | Trying a public chart first. |
| Existing Argo or Flux app | Read the source, target, rendered objects, and current status. | Teams that already use GitOps. |
| Rendered YAML | Import the files and show which objects ConfigHub would manage. | Applications already rendered by CI or Helm. |
| Live cluster | Inventory what is running before making any change. | Teams that need to understand an existing namespace. |
| Your own application | Bring your Deployments, Services, ConfigMaps, and policies beside catalog charts. | Private services and platform components. |
The Normal Order
Do not start by changing the cluster. Start by seeing the files, then group them, then make versions, then release.
Start with something real
Choose a catalog chart, an existing app, rendered YAML, a live namespace, or your own Kubernetes files.
Show the objects first
List the files and Kubernetes objects before ConfigHub changes how anything is delivered.
Name what belongs together
Group the objects that make up one application so a reviewer can see the whole thing.
Make versions
Create development, staging, production, region, or customer versions without copying values files by hand.
Release and check it
Send the approved files to GitOps or another delivery tool, then compare that with what the cluster reports.
Can I Start From An Existing App?
Yes. Start by reading it, not by replacing it. ConfigHub should show the source, target, namespace, objects, labels, and owner before it changes delivery.
| Starting point | First action | What you see |
|---|---|---|
| Argo CD app | Read or import the Argo app. | Source repo, target cluster, namespace, rendered objects, and current sync status. |
| Flux HelmRelease or Kustomization | Read or import the Flux object. | Controller source, target namespace, rendered objects, and ownership. |
| Rendered YAML | Import or preview the files. | Objects, labels, namespaces, Secrets, CRDs, and likely review points. |
| Live cluster | Inventory the namespace or selected objects. | What is running now, who appears to own it, and what would need review before adoption. |
| Platform services | Group related charts and files. | Which shared services belong with the application and which are separate platform dependencies. |
Start read-only
These commands are preview commands. They show what ConfigHub finds or would import before anything changes in the cluster.
New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.
cub gitops discover --space my-space my-k8s-target
cub gitops import --space my-space my-k8s-target my-render-target \
--where-resource "metadata.namespace = 'argocd'"
kubectl get all -n payments -o yaml > .tmp/payments.yaml
cub unit import payments-app .tmp/payments.yaml --dry-runYou see the resources, namespace, target, and source. At this stage nothing has been moved to ConfigHub delivery.
Only turn an existing app into a cub installer recipe when you want a maintained Helm render path, chart updates, and catalog-style checks. See Adopting Existing Apps.
Examples
| 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, the candidate moves through development and staging, and two Argo CD clusters run both the candidate OCI and the separately published rollback OCI.
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.
Chart evidence still lives on the Helm Ops Catalog pages. This page explains how those charts become part of applications your team runs.
Five working examples
Each row has a bounded example with committed evidence. The broader product capability remains partial until the missing work in the final column is complete.
| 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.