Argo CD ApplicationSet: Manage Many Applications as One

Why it exists

Manually creating and managing individual Argo CD Application resources for dozens of clusters or hundreds of microservices is tedious and error-prone. ApplicationSet was created to automate this process, treating a fleet of applications as a single, manageable set instead of many individual ones.

The mental model

An ApplicationSet is a 'for loop' for your Argo CD applications. You define a single Application template and a 'generator' that provides the parameters for the loop. The generator might loop over a list of clusters, a set of directories in a Git repository, or open pull requests. The controller then stamps out concrete Application resources for each item.

How it works

You define an ApplicationSet custom resource in Kubernetes. This resource has two main parts: a template and one or more generators. The template section looks just like a standard Argo CD Application manifest, but with placeholders for variables like {{cluster}} or {{path}}. The generator section defines how to find the values for these placeholders. For example, a ClusterGenerator discovers all clusters registered with Argo CD, while a GitGenerator can list directories in a repository. The ApplicationSet controller combines the generator's output with the template to render and apply the final Application resources.

When to use it

Use ApplicationSet when you need to deploy the same application to multiple clusters, such as across different regions or environments (dev, staging, prod). It's also perfect for monorepos where each service has its own directory that needs to be deployed as a separate application. It enables developer self-service by letting teams manage their own application definitions in a structured way that the ApplicationSet can automatically discover and deploy.

When not to use it

If you only manage a handful of applications on a single cluster, ApplicationSet is likely overkill. A few manually defined Argo CD Application resources are simpler to manage in that scenario. It adds a layer of abstraction that isn't necessary for small-scale or highly heterogeneous deployments that don't follow a repeating pattern.

One canonical example

A common pattern is managing an application across dev, staging, and production clusters. An ApplicationSet with a ListGenerator can define these three environments. The template defines the application itself, using a variable like {{environment}} to target the correct destination cluster and pull the correct configuration (e.g., values-dev.yaml). The result is three distinct Argo CD Application resources, all managed from one ApplicationSet manifest.