Skip to content
Browse the site

Deep Dives

AI: Claude and Codex patterns

ConfigHub: Deploy and manage

Configs
Stacks
Apps
Plugins
Guides
Docs

Before and after

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.

Before and after

Before: one of many overlays
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: apptique-prod

resources:
  - ../base/apptique
  - namespace.yaml

labels:
  - pairs:
      environment: prod

images:
  - name: nginx
    newTag: 1.26.3-alpine

patches:
  - target:
      kind: Deployment
      name: frontend
    patch: |
      - op: replace
        path: /spec/replicas
        value: 4

apps/prod/kustomization.yaml. You read files like this to work out what each environment runs.

After: in ConfigHub
ConfigHub showing the apps layer's base with a variant for each cluster, and the settings prod-1 changes

Taken in the helm-catalog organization on 2026-10-25, showing the apps layer's base with a variant for each cluster, and the settings prod-1 changes.

Each variant is one Unit in ConfigHub, holding everything its layer applies on that cluster.

Clusternginx version
dev-11.27.3-alpine
staging-11.27.2-alpine
prod-11.26.3-alpine

This is what the repository says each cluster should run. Nothing here reads a live cluster.

  • Each layer is one base, with a variant for each cluster that runs it.
  • Prod-1's changes are listed in one place, here nginx 1.26.3 and 4 replicas.
  • Dev, staging and prod are stages in that order, so a version moves from one to the next.

What you work out today, and what happens here instead

TodayHere instead
Image automation writes new tags into the dev overlay.It keeps doing so, and the plan names it, so you know dev's version can change without a review.
A HelmRelease pins edge-router to 2.4.x, so its version can change at any reconcile.The plan says to pin one exact version, so what runs changes only when a release says so.

ConfigHub keeps configuration as plain objects, with a history of every change. A base holds what every environment shares, and a variant is one environment's copy that stays linked to its base and lists what it changes.

Load it into your ConfigHub

Sign in, then paste the rest. It fetches the example, works out what each environment runs, and saves it in your organization. It touches no cluster, and Flux keeps reconciling Git until you run handover.sh, the step that moves each cluster onto ConfigHub's releases.

$ cub auth login

$ git clone https://github.com/confighub/examples.git && git -C examples checkout 7f1b8f2fc849bb6488bc2c58f1469172018fc9dd

$ cd examples/gitops/flux/expert-fleet

$ cub flux apply . --require Healthy --prefix fleet --out onboard

$ CONFIGHUB_OCI=oci.hub.confighub.com bash onboard/apply.sh

You need a ConfigHub account and cub with the flux plugin and kustomize.

Try it on your laptop

No account needed. This fetches the example and shows what each environment runs. In your own Flux repository, run the last line from its root.

$ git clone https://github.com/confighub/examples.git && git -C examples checkout 7f1b8f2fc849bb6488bc2c58f1469172018fc9dd

$ cd examples/gitops/flux/expert-fleet

$ cub flux plan . --require Healthy

You need cub with the flux plugin and kustomize.

Show me the details (for experienced users)