App-of-Apps Pattern vs ApplicationSets

App-of-apps is a pattern, not a feature. One parent Argo CD Application points at a directory of YAML files. Those YAML files are themselves Argo CD Application CRs. Argo CD syncs the parent, which creates the children, which deploy actual workloads. It gives you one bootstrap entry point per cluster: install the parent, everything else shows up. ApplicationSet is a controller that does something similar but template-driven. You write one Application template plus a generator (Git directory, list, cluster, matrix, pull request, SCM provider) and the controller produces N Applications from it. Add a new directory under overlays, an Application appears. Open a pull request, a preview Application appears. Close it, the preview gets cleaned up. Use ApplicationSets when: 1. You ship the same app across many environments or clusters and the only difference is a parameter (path, cluster URL, namespace). 2. You want pull-request preview environments. 3. Environments come and go often enough that hand-editing Application YAML is annoying. Use app-of-apps when: 1. Each Application is genuinely different. A monitoring stack, an ingress controller, and three apps do not fit one template. 2. You want a clear, hand-reviewed list of cluster components in Git. Real setups use both. App-of-apps bootstraps the platform layer (cert-manager, ingress, monitoring, the ApplicationSet controller itself). ApplicationSets generate per-environment Applications for actual workloads. The platform is curated; the apps are templated. One gotcha to mention. Deleting an ApplicationSet by default deletes every Application it generated, and Argo CD will then delete the workloads those Applications managed. Set preserveResourcesOnDeletion: true on the ApplicationSet spec if you do not want that cascade, or use a Finalizer carefully.