Using Argo CD ApplicationSet to Automate Multi‑Environment Deployments

What You’ll Gain

Argo CD’s ApplicationSet controller lets you generate many Argo CD Application resources from a single template. In practice this means you can spin up a new deployment for every branch, environment, or cluster with minimal manual effort. The result is a declarative, version‑controlled method to manage hundreds of applications without writing repetitive YAML files.

How ApplicationSet Works

The controller watches ApplicationSet custom resources (CRDs). Each ApplicationSet defines:

• generators – a list of data sources (Git, Helm, List, Cluster) that supply rows of values.
• template – a Go template that renders a standard Application spec for each row.
• Optional syncPolicy and destination overrides.

For every row produced by a generator, the controller creates or updates an Application that matches the rendered template. Changes to the ApplicationSet trigger reconciliation, ensuring the desired set of applications is always present.

Key Components

Component	Description
ApplicationSet CRD	Defines generators and template.
Generator	Source of rows (e.g., Git repo list).
Template	Go template producing an Application spec.
ApplicationSet Controller	Reconciles the resource and creates Applications.

Practical Example: Deploying a Helm Chart to Multiple Environments

Below is a complete ApplicationSet that:

• Uses a List generator to iterate over two environments: dev and prod.
• Injects the environment name into the chart values.
• Creates an Application for each environment pointing to the same Helm chart repository.

Save the file as demo-appsets.yaml and apply it in the argocd namespace.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my‑app‑set
  namespace: argocd
spec:
  generators:
  - list:
      elements:
      - env: dev
        namespace: dev-ns
      - env: prod
        namespace: prod-ns
  template:
    metadata:
      name: {{ .env }}-app
    spec:
      project: default
      source:
        repoURL: https://github.com/example/helm-charts.git
        targetRevision: HEAD
        chart: my‑chart
        helm:
          values: |
            env: {{ .env }}
      destination:
        server: https://kubernetes.default.svc
        namespace: {{ .namespace }}
      syncPolicy:
        automated:
          prune: true
          selfHeal: true

Running the Example

1. Ensure the ApplicationSet controller is installed:

   helm repo add argo https://argoproj.github.io/argo-helm
   helm install argo-cd argo/argo-cd \
     --namespace argocd \
     --create-namespace \
     --set applicationset.enabled=true
   

2. Apply the ApplicationSet:

   kubectl apply -f demo-appsets.yaml -n argocd
   

3. Verify the Applications were created:

   kubectl get applications -n argocd
   

   Expected output includes dev-app and prod-app.
4. Trigger a sync on one of them:

   argocd app sync dev-app
   

   Check the target namespaces to confirm the chart was installed.

RBAC and Permissions

The ApplicationSet controller runs as a ServiceAccount (default: argocd-applicationset). That account must have:

• create and update rights on applications in the target namespaces.
• Read access to the Git repo or Helm chart repository if the generator references external sources.

Typical RoleBinding for the controller:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: applicationset-access
  namespace: argocd
subjects:
- kind: ServiceAccount
  name: argocd-applicationset
  namespace: argocd
roleRef:
  kind: ClusterRole
  name: argocd-application-controller
  apiGroup: rbac.authorization.k8s.io

Common Pitfalls & Limits

• Missing Controller: The standard Argo CD Helm chart does not enable ApplicationSet by default. Forgetting to set applicationset.enabled:true results in the controller not running.
• Large Generators: A List generator with thousands of items can overwhelm the API server and cause reconciliation timeouts. Use pagination or split into smaller sets.
• Template Errors: A typo in the Go template (e.g., {{ .env }} vs {{ .Env }}) causes the controller to log errors and skip creation. Inspect logs: kubectl logs -n argocd -l app.kubernetes.io/name=argocd-applicationset.
• Namespace Quotas: If the target namespace has resource quotas, the generated Application may fail to sync. Verify quotas before deploying.
• Sync Failures due to Repo Permissions: The ServiceAccount must have read access to the Git repo. If using a private repo, configure the argocd-cm repositories entry with credentials.

Verifying Success

After applying the ApplicationSet, run:

kubectl get applications -n argocd

Each row in the list generator should correspond to a created Application. The argocd app get <app-name> command shows sync status and any errors.

To confirm that the generated applications are indeed managing resources, check the target namespace:

kubectl get all -n dev-ns

All resources defined by the Helm chart should be present.

When to Use ApplicationSet

• Automating deployment of the same application to multiple environments or clusters.
• Implementing blue‑green or canary strategies by generating distinct Applications for each variant.
• Managing a fleet of microservices where each service has its own Application but shares common configuration.

Next Steps

Once you’re comfortable with a simple list generator, explore more advanced generators:

• Git – iterate over branches or directories in a repo.
• Helm – generate applications based on chart values files.
• Cluster – create an application per cluster in a multi‑cluster setup.

Combine generators with syncPolicy and retry settings to fine‑tune deployment behavior.

Conclusion

Argo CD ApplicationSet turns a repetitive, error‑prone process into a single declarative manifest. With careful RBAC configuration and awareness of generator limits, you can scale deployments across environments, branches, or clusters with minimal maintenance.