Before and after
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: apptique
namespace: argocd
spec:
generators:
- git:
repoURL: https://github.com/confighub/examples.git
revision: main
directories:
- path: gitops/argo/beginner-applicationset/apps/apptique/overlays/*
template:
metadata:
name: 'apptique-{{path.basename}}'
labels:
app.kubernetes.io/name: apptique
app.kubernetes.io/instance: 'apptique-{{path.basename}}'
environment: '{{path.basename}}'
spec:
project: default
source:
repoURL: https://github.com/confighub/examples.git
targetRevision: main
path: '{{path}}'
destination:
bootstrap/applicationset.yaml, its first 26 of 34 lines. You read files like this to work out what each environment runs.
Taken in the helm-catalog organization on 2026-10-25, showing the base with the two variants the ApplicationSet generates, and the settings prod changes.
Each variant is one Unit in ConfigHub, holding everything its Application deploys.
- The two Applications the template would make are written out as variants of one base.
- Prod's changes from the base are listed in one place: namespace, label, 3 replicas and its resources.
- Nothing is generated on the cluster before you have read it.
What you work out today, and what happens here instead
| Today | Here instead |
|---|---|
| An ApplicationSet makes Applications from a template on the cluster, so you never see them before they exist. | The template is filled in here, one Application per environment, each a variant of one base. |
| The ApplicationSet was applied by hand. | It stays in the cluster. The plan says handover must patch it or repoint its Applications one by one. |
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.
Show me the details (for experienced users)