Redis, before and after
The Redis chart makes 14 objects. Your password stays put. The Helm chart makes a new one every time it runs, and here you create it once.
See a config before and after
Each example shows the files you may have today next to the same thing in ConfigHub. You can load any of them into your own ConfigHub with one paste.
Go to Helm charts, Kustomize, Argo CD, Flux or Apps.
PostgreSQL, before and after
The PostgreSQL chart makes 7 objects. Your password stays put. The Helm chart makes a new one every time it runs, and here you create it once.
ingress-nginx, before and after
The ingress-nginx chart makes 18 objects. The 7 setup objects Helm runs out of sight become steps you can read.
cert-manager, before and after
The cert-manager chart makes 50 objects. The 4 setup objects Helm runs out of sight are left out, so nothing runs that you didn't see.
kube-prometheus-stack, before and after
The kube-prometheus-stack chart makes 122 objects. The 7 setup objects Helm runs out of sight become steps you can read.
Argo CD, before and after
The Argo CD chart makes 59 objects. The 4 setup objects Helm runs out of sight become steps you can read.
External Secrets, before and after
The External Secrets chart makes 44 objects. Every object is written out, so you can review it before anything runs.
metrics-server, before and after
The metrics-server chart makes 9 objects. Every object is written out, so you can review it before anything runs.
Gatekeeper, before and after
The Gatekeeper chart makes 21 objects. The 8 setup objects Helm runs out of sight become steps you can read.
NVIDIA GPU Operator, before and after
The NVIDIA GPU Operator chart makes 27 objects. The 8 setup objects Helm runs out of sight become steps you can read.
Kustomize dev and prod, before and after
A base and two overlays become one base with dev and prod variants, and prod's changes are listed in one place.
A Helm chart inside Kustomize, before and after
A Helm chart inflated by Kustomize becomes one base with a variant per environment, and prod's changes are listed in one place.
An Argo CD app of apps, before and after
Your Argo CD apps are held in ConfigHub as a base and a variant for each cluster, while Argo CD keeps syncing Git.
An Argo CD ApplicationSet, before and after
An ApplicationSet's template becomes the Applications it would make, each a variant of one base, with prod's changes listed in one place.
A Flux fleet, before and after
Your Flux layers are held in ConfigHub as a base and a variant for each cluster, while Flux keeps reconciling Git.
Which version runs where, before and after
Three clusters and four layers become one base per layer with a variant for each cluster, so you can see which version Git says each cluster runs.
The shop-web app, before and after
An app's YAML never says what the cluster must already run. ConfigHub lists what the app needs, and checks it against a platform.
See what changes—and what stays yours
Keep your app, your Git repos, and the Argo CD or Flux setup you already use. Start by seeing exactly what a change would do. When you’re ready, bring that configuration into ConfigHub so your team can review, approve and release it together.
- Look first. Preview the configuration and compare a change. You need no cluster for this step.
- Try ConfigHub alongside Git. Import a copy of the configuration. Your controller keeps reading Git.
- Switch when you’re ready. Review the delivery changes and the way back before asking your controller to use ConfigHub releases.
You can point the controller back to its previous source. That does not undo database writes or other changes the app has made. Use the Argo CD guide or Flux guide for the steps.
Browse all examples, or choose a change below to see the before and after.
Add frontend replicas without losing sight of the database
Try a small change to a complete app, then see what it shares with other environments.
Walk through this change
App and dependencies: a frontend, backend, and PostgreSQL StatefulSet, connected through a layered recipe.
Before ConfigHub: the example starts with development settings. Its flattened configuration is fully rendered Kubernetes YAML, rather than chart templates. App code, images, and delivery stay in their own workflows.
With ConfigHub: see the replica change alongside the rest of the app and keep a record of where its configuration came from. A base is shared starting configuration; a variant adds choices for one environment. A target and apply are separate steps.
Try: raise the frontend replica count in a deployment variant and compare it with the shared base.
AI guide · Manual next: the first-app walkthrough
Open the realistic-app example. Its local preview is read-only; successful Unit verification does not prove that the app is serving requests.
Promote the tag you reviewed
Catch a wrong image tag before it reaches production.
Walk through this change
App and dependencies: one frontend, two Git repositories, and separate Argo CD Applications for dev and prod.
Before ConfigHub: CI proposes the dev image tag; a second pull request promotes that same tag to prod.
With ConfigHub: render each environment into its own Space and inspect the actual image-field diff alongside Git’s separate promotion record.
Try: change the prod tag without updating its promotion record; the example’s verifier catches the mismatch.
AI guide · Manual next: bring an Argo CD estate into ConfigHub
Open the dev-to-prod example. Its CI and promotion workflows are illustrative; the example does not install Argo CD or deploy to a live cluster.
See what your AI app needs to run
Choose a model and see which services and resources the app needs. Live NIM needs x86_64, NVIDIA hardware and credentials.
Walk through this change
App and dependencies: rag-server, NIM language and embedding services, and a vector database.
Before ConfigHub: model images, GPU placement, and service connections sit across several component configurations.
With ConfigHub: the example layers the four components and records direct, Flux, and Argo variants so a model-profile change has a traceable path.
Try: change the LLM and embedding model names at the shared profile layer, then inspect how that choice flows toward each deployment variant.
AI guide · Manual next: compare GPU nodes and AICR requirements
Open the Enterprise RAG example. Its runnable NIM path requires x86_64, NVIDIA hardware, and NGC credentials. This Apps page does not claim live GPU success; recipe verification and local Ollama queries do not prove NIM runtime on your cluster.
Every worked example app
Each app links to its repository's default branch. The last column is the commit at which it was last checked.
| App | What it shows | Delivered by | Checked at |
|---|---|---|---|
| The shop app, five journeys | A small shop app built with an AI assistant, followed through five journeys: ineffective Helm values, fixes that survive regeneration, platform requirements, a Redis migration before Argo CD takes over, and an image that no longer exists. | Plain | e0a525a |
| storefront | A shop service for the storefront: a Deployment and a Service in namespace retail. | Plain | 8f4c207 |
| cart | A shop service for the cart: a Deployment and a Service in namespace retail. | Plain | 8f4c207 |
| checkout | A shop service for checkout: a Deployment and a Service in namespace retail. | Plain | 8f4c207 |
| catalog-api | A shop service for the product catalog API: a Deployment and a Service in namespace retail. | Plain | 8f4c207 |
| search | A shop service for search: a Deployment and a Service in namespace retail. | Plain | 8f4c207 |
| identity | A shop service for identity: a Deployment and a Service in namespace auth. | Plain | 8f4c207 |
| fraud-scoring | A shop service for fraud scoring: a Deployment and a Service in namespace payments. | Plain | 8f4c207 |
| ledger | A shop service for the ledger: a Deployment and a Service in namespace payments. | Plain | 8f4c207 |
| payment-gateway | A shop service for the payment gateway: a Deployment and a Service in namespace payments. | Plain | 8f4c207 |
| shipment-tracker | A shop service for shipment tracking: a Deployment and a Service in namespace logistics. | Plain | 8f4c207 |
| warehouse-api | A shop service for the warehouse API: a Deployment and a Service in namespace logistics. | Plain | 8f4c207 |
| shop-web | The shop web front end, with an Ingress, a Certificate and a ServiceMonitor, so it needs ingress, cert-manager and Prometheus from its platform. | Plain | 8f4c207 |
| shop-web on Kubara | shop-web adapted to the Kubara platform: Traefik's ingress class and a Secret pulled through External Secrets. | Plain | 8f4c207 |
| hello-standalone | The smallest app: one Deployment and one Service, with nothing asked of the platform. | Plain | 8f4c207 |
| Argo CD beginner: app of apps | One app in a small, realistic Argo CD repository, delivered through an app of apps. | Argo CD | 148890b |
| Argo CD beginner: ApplicationSet | One app in a small, realistic Argo CD repository, delivered through an ApplicationSet. | Argo CD | 148890b |
| Argo CD intermediate: CI to GitOps | CI writes image tags, and promotion happens by pull request, across an app repository and a config repository. | Argo CD | 148890b |
| Argo CD intermediate: Git as a database | An Argo CD fleet repository that demonstrates seven habits which make a config repository act like a database, including layered values, registered clusters and an in-repo chart. | Argo CD | 7f1b8f2 |
| Argo CD expert: app of apps on three clusters | A brownfield Argo CD layout of the kind a platform team runs, across three clusters. | Argo CD | 148890b |
| Flux beginner | One app in a small, realistic Flux repository with the standard layout. | Flux | 148890b |
| Flux expert: a three-cluster fleet | A Flux fleet repository with layered Kustomizations, a tenant, image automation and branch-based promotion. | Flux | 148890b |
| Spring platform with generators | Why platform teams want generators: a Spring app whose configuration cub-gen produces and checks. | A generator | 148890b |
| Kubernetes to Score | Converts the Kubernetes resources in a ConfigHub Space into a Score workload. | A generator | 148890b |
| A realistic three-component app | A frontend, a backend and PostgreSQL as one global-app recipe, with optional Ollama. | Plain | 148890b |