What are the Argo CD app-of-apps and ApplicationSet patterns and when do you use each?

Both patterns solve the same problem — managing many Argo CD Applications without manually applying each one — but they use different mechanisms and suit different scales.

App-of-apps: A parent Argo CD Application has its source.path pointing to a Git directory that contains child Application YAML manifests. When Argo CD syncs the parent, it applies those Application CRs into the argocd namespace. Each child Application then manages its own workload independently. The child Application YAMLs are static files you write by hand and commit to Git.

# Parent Application (the "root app")
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
  namespace: argocd
spec:
  source:
    repoURL: https://github.com/org/gitops-config.git
    targetRevision: main
    path: argocd/apps          # this folder holds child Application CRs
  destination:
    server: https://kubernetes.default.svc
    namespace: argocd
  syncPolicy:
    automated:
      prune: true

ApplicationSet: A CR managed by the ApplicationSet controller. Instead of static Application files, you define a template and one or more generators. The controller creates, updates, and deletes Application CRs automatically as generators produce or remove parameter sets. No need to manually add/remove Application YAML files when a new service or cluster is onboarded.

When to use each:

• App-of-apps: small, relatively static set of applications; you want explicit per-Application YAML for full control and diff visibility; or you need per-Application customisations that generators can't express concisely.
• ApplicationSet: large number of applications; dynamic inputs (new directories in Git, new clusters registered); need to scale without manual YAML maintenance. The matrix and merge generators allow powerful combinatorial deployments.