1. 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.