Generate Argo CD Applications Automatically with ApplicationSet

The Problem: One Application Manifest Per Cluster Does Not Scale

You run Argo CD in a central management cluster and deploy the same platform add-on—logging, monitoring, or an ingress controller—to every workload cluster. At first, copying an Application manifest and changing the destination server is manageable. Once you have a dozen clusters, or customer-specific environments, the copy-paste burden grows. A chart version bump means editing dozens of files. A missed file means drift.

Takeaway: Argo CD's ApplicationSet controller can generate Application resources automatically from a single template. The cluster generator discovers clusters registered with Argo CD and creates one Application for each, so adding a cluster to Argo CD also adds the Application—no manual YAML required.

How the Cluster Generator Works

ApplicationSet is available in Argo CD v2.0 and later. Generator fields can change between releases, so check the documentation for your installed version before adopting new syntax.

When you register a cluster with Argo CD—for example, with argocd cluster add—Argo CD stores the cluster credentials in a Kubernetes Secret labeled argocd.argoproj.io/secret-type: cluster. A Secret is a Kubernetes object for sensitive data; here it holds the API server address and credentials for a registered cluster. The ApplicationSet controller watches these secrets. For every matching secret, it renders your template and creates an Application, substituting variables such as ${cluster.name} and ${cluster.server}.

The controller reconciles on its own interval. If you register a new cluster, the generated Application appears after the next reconciliation cycle—expect minutes, not seconds. If you remove a cluster, the controller removes the generated Application.

Worked Example: Deploy a Logging Add-on to Every Cluster

This ApplicationSet deploys a Helm chart called platform-logging to the observability namespace on every cluster registered with Argo CD.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: platform-logging
  namespace: argocd
spec:
  generators:
    - clusters: {}
  template:
    metadata:
      name: 'logging-${cluster.name}'
      namespace: argocd
    spec:
      project: default
      source:
        repoURL: https://charts.internal.example.com
        chart: platform-logging
        targetRevision: 1.0.0
      destination:
        server: '${cluster.server}'
        namespace: observability
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Where to run: Apply from a workstation or CI runner with kubectl access to the Argo CD namespace.

kubectl apply -f platform-logging-applicationset.yaml -n argocd

Permissions: Your user or service account needs permission to create ApplicationSet resources in the argocd namespace. The Argo CD ApplicationSet controller itself needs permission to create, update, and delete Application resources; this is typically allowed by default, but verify your RBAC if generated Applications do not appear.

Expected result: One Application named logging-<cluster-name> per registered cluster, each pointing to that cluster's API server.

Verification:

kubectl get applicationset platform-logging -n argocd
kubectl get applications -n argocd

Look for the platform-logging ApplicationSet, then confirm generated Applications appear with names matching your clusters. If no Applications appear, check the ApplicationSet status and the Argo CD controller logs for RBAC or template errors.

Risk: Because clusters: {} matches every registered cluster, this can create many Applications at once. Start with one add-on in a non-production Argo CD instance.

Trade-offs and Limitations

RBAC scope is broad

The cluster generator reads all cluster secrets in the Argo CD namespace. In a multi-tenant installation, the controller can see clusters belonging to different teams. Limit who can create ApplicationSets, and consult your Argo CD documentation for generator filtering options if you need to restrict which clusters are included.

No built-in rollout ordering

ApplicationSet creates each Application independently. It does not coordinate a canary or wave-based rollout across clusters. If you need to deploy to staging before production, model that in your source repository or use separate ApplicationSets per environment rather than one generator for all clusters.

Not the right tool for every topology

• List generator: Use when you have a static set of clusters or environments that are not all registered in Argo CD.
• Git generator: Use when your repository directory structure defines the targets, such as one folder per environment.
• Matrix generator: Use when you need combinations, such as every service in every region. It multiplies Application count quickly, so use it sparingly.

Actionable Next Step

Choose one platform add-on that you currently manage with manual Application manifests. Write an ApplicationSet using the cluster generator, apply it to a non-production Argo CD instance, and confirm that generated Applications become Synced and Healthy. Once verified, migrate additional add-ons one at a time. Keep the manual manifests until the generated replacements are healthy across all target clusters, then remove them with kubectl delete -f platform-logging-applicationset.yaml -n argocd.