Applications in Argo CD can be created by the UI, CLI, or by applying a manifest file in Kubernetes (declarative setup, mono application). Mono application is where an application is exported or written as a manifest file with the type of Application

Application and ApplicationSet

An Argo CD Application is the core GitOps resource that defines what to deploy, where to deploy it (cluster and namespace), and how to keep it in sync with a Git repository. You specify a repo URL, a path inside the repo, a destination, and optional sync settings. It results in one managed deployment that Argo CD reconciles against your cluster state

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  source:
    repoURL: https://github.com/example/repo
    path: apps/my-app
  project: default
  syncPolicy:
    automated: {}

An ApplicationSet is a higher-level Argo CD resource that automatically generates multiple Application objects from one template and a set of input parameters (like a list of clusters, Git branches, etc.). Instead of writing many Application manifests manually, you define generators and a template in the ApplicationSet, and the controller creates, updates, or deletes the corresponding Application resources for you. This is useful for multi-cluster, multi-environment, or many similar applications

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: my-appset
spec:
  generators:
    - list:
        elements:
          - cluster: dev
            url: https://dev.example.com
          - cluster: prod
            url: https://prod.example.com
  template:
    metadata:
      name: '{{cluster}}-my-app'
    spec:
      project: default
      source:
        repoURL: https://github.com/example/repo
        path: apps/my-app
      destination:
        server: '{{url}}'
        namespace: default

Generators

In Argo CD’s ApplicationSet, generators take a data source and turn it into a set of parameters that get fed into the template so many Application resources can be created automatically based on that input instead of writing each one by hand. Common generators include the list generator (uses a simple list of key/value pairs you define), the cluster generator (pulls registered Argo CD clusters and exposes fields like name and server), and the matrix generator (combines two generators so you can, for example, deploy multiple apps across multiple clusters)

Example: using a list generator you might define two apps with names and namespaces, and the controller will generate parameters for each item that get substituted in the template to create separate Application objects for “atlantis” and “crossplane” with appropriate values injected from the list

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: example
spec:
  generators:
    - list:
        elements:
          - appName: atlantis
            namespace: automation
          - appName: crossplane
            namespace: crossplane-system
  template:
    metadata:
      name: "example"
    spec:
      source:
        helm:
          valueFiles:
            - "{{ appName }}-values.yaml"
      destination:
        namespace: "{{ namespace }}"

App of apps

A pattern of deploying and managing a group of applications using a single top-level Argo CD application which manages multiple mono applications then the mono applications execute the manifest files each with its own Git repository and path

Multiple interdependent applications, each with its own unique requirements and deployment process. Any changes made to the top level will trigger to all of the managed applications

Say the following example has the app-of-apps.yaml file the top level which executes the app1.yaml and app2.yaml mono apps, the mono apps then execute each of the targeted manifest files accordingly. It doesn’t has to be in the same repository or the same structure

Folder structure

Example
├───app-of-apps
│       app1.yaml
│       app2.yaml
├───manifests
│   ├───app1
│   │       deployment.yaml
│   │       service.yaml
│   └───app2
│           deployment.yaml
│           service.yaml
└───top-level
        app-of-apps.yaml

Top level file

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-of-apps
  namespace: Argo CD
spec:
  project: default
  source:
    repoURL: <Git_URL>
    targetRevision: HEAD
    # where the mono apps are located
    path: <./path/to/manifest>
  destination:
    server: https://kubernetes.default.svc
    namespace: Argo CD
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Mono app file