Your team hand-maintains around two hundred Argo CD Application manifests across several clusters. How would you decide whether to replace them with ApplicationSet generators, and what risks does that introduce?

## The real question is not tooling Two hundred Application manifests are a smell only if they are *repetitive*. The test to apply: pick three of them at random and diff. If the differences are a name, a path, a destination and maybe an image tag, the set is derived from data and hand-maintenance is pure transcription cost. If each one carries genuinely different sync policy, ignore rules, project and source layout, then they are authored artefacts and templating them will produce a generator template riddled with conditionals — harder to read than the two hundred files were. ## What ApplicationSet is `ApplicationSet` is a second Argo CD CRD, handled by its own controller, that produces `Application` objects. It has two halves: - `spec.generators` — one or more sources of parameters. - `spec.template` — an `Application` skeleton with placeholders filled from those parameters. ```yaml apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: checkout-per-cluster namespace: argocd spec: goTemplate: true generators: - clusters: selector: matchLabels: env: prod template: metadata: name: 'checkout-{{.name}}' spec: project: payments source: repoURL: https://github.com/acme/manifests.git path: apps/checkout/overlays/prod targetRevision: v1.8.3 destination: server: '{{.server}}' namespace: checkout syncPolicy: automated: prune: true selfHeal: true ``` The generated objects are ordinary Applications: everything you know about `syncPolicy`, `ignoreDifferences` and sync waves still applies. ## Choosing a generator - **list** — an explicit array of parameter sets. Honest and readable when the set is small and genuinely hand-picked. - **clusters** — one Application per cluster registered with Argo CD, filterable by label. The natural fit for "this platform component belongs on every production cluster". - **git** — directory mode creates one Application per directory matching a pattern (the "app of apps by convention" model: adding a folder adds an app); file mode reads config files in the repo and uses their contents as parameters, which keeps the data explicit and reviewable. - **matrix** / **merge** — combine two generators, most often *apps × clusters*, or overlay per-cluster overrides on a base list. - **scmProvider** / **pullRequest** — enumerate repositories in an organisation, or open pull requests, the latter being how ephemeral preview environments are built and torn down automatically. Git *file* generators tend to age better than directory generators at scale, because the parameters are visible data in a reviewed file rather than an emergent property of the folder tree. ## The risks you must name **Concentration of blast radius.** A typo in `template` no longer breaks one app; it rewrites all of them on the next reconcile. This is the central tradeoff — you traded two hundred small, independently reviewable objects for one large, powerful one. **Cascading deletion.** Generated Applications are owned by the ApplicationSet. Delete or narrow the generator and the Applications go, and with `prune: true` in the template, their workloads go too. `spec.syncPolicy.preserveResourcesOnDeletion: true` keeps the deployed resources when a generated Application disappears; `applicationsSync: create-only` or `create-update` restricts the controller from deleting at all. On a production ApplicationSet, at least one of those should be set before you rely on it. **Silent set changes.** With a `clusters` generator, registering a new cluster deploys to it immediately; with a `git` directory generator, adding a folder does. That is the feature, and it is also how something reaches production without anyone reviewing a deploy. Decide deliberately which generator's input is a reviewed artefact. **All-at-once rollout.** Changing `targetRevision` in the template updates every generated Application simultaneously. Where supported, `spec.strategy` progressive syncs let you roll the change through labelled groups of Applications in steps rather than all at once; otherwise, stage the change by splitting into more than one ApplicationSet. ## A defensible migration 1. Start with the clearest repetitive family — one platform component across all clusters — not the whole estate. 2. Generate into a non-production project first and diff the produced Applications against the hand-written ones. 3. Set `preserveResourcesOnDeletion` and a restrictive `applicationsSync` before pointing it at anything that matters. 4. Put the ApplicationSet in Git, require review on it, and treat template changes with the same gravity as a change to every service it generates — because that is what they are. 5. Leave genuinely bespoke Applications hand-written. A hybrid is the normal end state, not a failure. The principal-level judgment is knowing that ApplicationSet moves work rather than removing it: less transcription, more concentrated risk, and a new question about who is allowed to change the generator's input.