See what an Argo CD ApplicationSet becomes

An ApplicationSet is a template with placeholders, and Argo CD fills them in on the cluster. The plan writes out the 2 Applications it would generate, so you can read them before Argo CD makes them, and ConfigHub holds a base and a variant for each.

What you need. git and cub with the argo plugin. No account and no cluster.

1. See what you have today

The example is an ApplicationSet in confighub/examples. Its git directory generator makes one Application for each directory under overlays/.

File	What it is
`apps/apptique/base/deployment.yaml`	the Deployment frontend
`apps/apptique/base/kustomization.yaml`	a Kustomize file
`apps/apptique/base/service.yaml`	the Service frontend and the ServiceAccount frontend
`apps/apptique/overlays/dev/kustomization.yaml`	a Kustomize file
`apps/apptique/overlays/dev/namespace.yaml`	the Namespace apptique-dev
`apps/apptique/overlays/prod/kustomization.yaml`	a Kustomize file
`apps/apptique/overlays/prod/namespace.yaml`	the Namespace apptique-prod
`bootstrap/applicationset.yaml`	the ApplicationSet, applied by hand: one Application per directory under overlays/

Nothing in these files names the Applications. They exist only once Argo CD has run the generator.

2. See what ConfigHub would hold

The plan reads the files and says what ConfigHub would hold. It runs nothing and changes no cluster.

after: the plan for this ApplicationSet

$ cub argo plan .
Argo CD estate: 1 cluster, Argo CD's own (in-cluster), 1 components, 2 variants
Read 9 objects

One stage, fleet (pass --stage-label and --stages to roll out in waves)

apptique  (ApplicationSet, project default, wave 0)
  selects  2 directories under gitops/argo/beginner-applicationset/apps/apptique/overlays/*
  base     argo-apptique-base  reaches no cluster: its destination is empty
  each variant differs from the base in metadata.labels.app.kubernetes.io/instance, metadata.labels.environment, metadata.name, spec.destination.namespace, spec.source.path
  stage fleet
    dev         variant argo-apptique-dev  ->  Target argo-targets/in-cluster
                Application apptique-dev, namespace apptique-dev
                gitops/argo/beginner-applicationset/apps/apptique/overlays/dev
    prod        variant argo-apptique-prod  ->  Target argo-targets/in-cluster
                Application apptique-prod, namespace apptique-prod
                gitops/argo/beginner-applicationset/apps/apptique/overlays/prod

Handover, when this estate is live (apply will write it as handover.sh; plan runs nothing)
  1. check Argo CD is v3.1 or newer, which is where an oci:// source is read natively; an older one cannot do this at all
  2. ApplicationSet apptique is applied by hand, so its template cannot be repointed under review. Either patch the template in the cluster, or delete it with 'kubectl delete --cascade=orphan' and repoint apptique-dev, apptique-prod one by one. Orphaning is the fallback here, not the plan
  3. never delete every Application apptique generates: resources-finalizer.argocd.argoproj.io deletes everything it deployed. Every step above is a patch for exactly this reason

Next
  cub argo apply . --out ./argo-onboarding
  That writes apply.sh, handover.sh and cleanup.sh. It runs nothing.

3. See the Applications it would generate

These are the fields where the generated Applications differ, with the template line each one comes from.

Field	In the template	apptique-dev	apptique-prod
`metadata.name`	`apptique-{{path.basename}}`	`apptique-dev`	`apptique-prod`
`metadata.labels.app.kubernetes.io/instance`	`apptique-{{path.basename}}`	`apptique-dev`	`apptique-prod`
`metadata.labels.environment`	`{{path.basename}}`	`dev`	`prod`
`spec.destination.namespace`	`apptique-{{path.basename}}`	`apptique-dev`	`apptique-prod`
`spec.source.path`	`{{path}}`	`gitops/argo/beginner-applicationset/apps/apptique/overlays/dev`	`gitops/argo/beginner-applicationset/apps/apptique/overlays/prod`

Everything else in the two Applications is the template as written.

4. Try it yourself, with no account

Install cub and the argo plugin as Bring your Argo CD apps into ConfigHub shows, first.

# fetch the example at the commit this page was built from
$ git clone https://github.com/confighub/examples.git && git -C examples checkout 7f1b8f2fc849bb6488bc2c58f1469172018fc9dd

$ cd examples/gitops/argo/beginner-applicationset

# read the plan; it runs nothing
$ cub argo plan .

# write the generated Applications, and the scripts, to onboard/
$ cub argo apply . --out onboard

The generated Applications are in onboard/apps/.

See it live in ConfigHub

Everything above runs on your own machine with no account. To see the same example in ConfigHub, load it into your own organization with the commands below.

With your own account

# sign in to your organization
$ cub auth login

# fill ConfigHub with the base and variants the plan names; it changes no cluster
$ bash onboard/apply.sh

apply.sh also needs kustomize, and onboard/cleanup.sh takes everything back out.

5. Technical notes and disclaimers

The plan ran on 2026-10-26 with cub v0.9.0 and argo plugin 0.3.3, inside a checkout of the example. The recorded files and their receipt hold every input and output.
This ApplicationSet is applied by hand, so the handover cannot repoint its template under review. The plan says to patch the template in the cluster, or to delete it with --cascade=orphan and repoint each Application.
Never delete every Application it generates. Their finalizer deletes everything they deployed.