See what an Argo CD app of apps becomes

1. See what you have today

The example is an app of apps in confighub/examples. One root Application syncs two child Applications, and each child syncs one environment from Git.

File	What it is
`apps/apptique-dev.yaml`	an Application that syncs one environment's manifests from Git
`apps/apptique-prod.yaml`	an Application that syncs one environment's manifests from Git
`manifests/apptique/dev/deployment.yaml`	the Deployment that Application syncs
`manifests/apptique/prod/deployment.yaml`	the Deployment that Application syncs
`root/root-app.yaml`	the root Application, applied by hand, which syncs the apps directory

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 app of apps

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

Control tree (stays as it is: this is the management record)
  Application apptique-apps                  wave   0  root, applied by hand
    Application apptique-dev                 wave   0  deploys workloads; planned below
    Application apptique-prod                wave   0  deploys workloads; planned below

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

apptique-dev  (Application, project default, wave 0)
  base     argo-apptique-dev-base  reaches no cluster: its destination is empty
  each variant differs from the base in spec.destination
  stage fleet
    in-cluster  variant argo-apptique-dev-in-cluster  ->  Target argo-targets/in-cluster
                Application apptique-dev, namespace apptique-dev
                gitops/argo/beginner-app-of-apps/manifests/apptique/dev
  note     a plain directory of manifests, read as Argo CD reads it: every .yaml, .yml and .json file at the top level

apptique-prod  (Application, project default, wave 0)
  base     argo-apptique-prod-base  reaches no cluster: its destination is empty
  each variant differs from the base in spec.destination
  stage fleet
    in-cluster  variant argo-apptique-prod-in-cluster  ->  Target argo-targets/in-cluster
                Application apptique-prod, namespace apptique-prod
                gitops/argo/beginner-app-of-apps/manifests/apptique/prod
  note     a plain directory of manifests, read as Argo CD reads it: every .yaml, .yml and .json file at the top level

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. repoint Application apptique-apps at argo-apptique-apps-children, which would hold Application apptique-dev, Application apptique-prod. Publish that Space first: a parent left syncing an empty source prunes its children. Nothing above it syncs it, so patch its spec.source in the cluster.
  3. never delete apptique-apps, apptique-dev, apptique-prod: 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 what changes in each Application

After the handover each child Application reads a ConfigHub release instead of Git. These are the only fields that change.

Application	Field	Before	After
apptique-dev	`spec.source.path`	`gitops/argo/beginner-app-of-apps/manifests/apptique/dev`	`.`
apptique-dev	`spec.source.repoURL`	`https://github.com/confighub/examples.git`	`oci://<gateway>/space/argo-apptique-dev-in-cluster`
apptique-dev	`spec.source.targetRevision`	`main`	`latest`
apptique-prod	`spec.source.path`	`gitops/argo/beginner-app-of-apps/manifests/apptique/prod`	`.`
apptique-prod	`spec.source.repoURL`	`https://github.com/confighub/examples.git`	`oci://<gateway>/space/argo-apptique-prod-in-cluster`
apptique-prod	`spec.source.targetRevision`	`main`	`latest`

The finalizer, the sync policy and the destination stay as they are. <gateway> is the OCI address your ConfigHub serves releases from.

The root Application apptique-apps also changes only its source. It moves to the Space argo-apptique-apps-children, which holds the two child Applications, as step 2 of the handover says.

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-app-of-apps

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

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

Compare onboard/control/ with onboard/repointed/ to see the table above for yourself.

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 bases and variants the plan names; it changes no cluster
$ bash onboard/apply.sh

apply.sh also needs kustomize. onboard/cleanup.sh takes everything back out. The handover, which moves Argo CD onto ConfigHub releases, is a separate step in the Argo CD Guide.

What it looks like in ConfigHub

ConfigHub showing the apptique-prod base with its in-cluster variant, and the prod Deployment's settings — The helm-catalog organization on 2026-10-25, showing the apptique-prod base with its in-cluster variant, and the prod Deployment's settings. It was loaded as this panel describes.

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.
An oci:// source needs Argo CD v3.1 or newer. The plan checks this before the handover.
Never delete these Applications to undo the handover. Their finalizer deletes everything they deployed.