Scale ArgoCD across teams and many apps — group and constrain applications with Projects, and manage dozens of apps declaratively with the app-of-apps pattern.
Why: as teams and apps multiply, you need boundaries. An AppProject groups Applications and constrains what they may do — which git repos they can deploy from, which clusters and namespaces they can target, which resource kinds are allowed. It is how you give a team a safe, fenced-off slice of ArgoCD.
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-web
namespace: argocd
spec:
sourceRepos:
- https://github.com/myorg/* # only these repos
destinations:
- server: https://kubernetes.default.svc
namespace: web-* # only these namespaces
clusterResourceWhitelist: [] # no cluster-scoped resourcesWhy: managing fifty Applications by hand defeats the purpose. The app-of-apps pattern uses ONE parent Application whose git source is a folder of child Application manifests. ArgoCD syncs the parent, which creates all the children, which deploy the actual workloads. You bootstrap an entire environment from a single root app.
root Application ──points at──▶ git folder of Application manifests
│
├─▶ Application: web ──▶ deploys the web workloads
├─▶ Application: api ──▶ deploys the api workloads
└─▶ Application: redis ──▶ deploys redis
(sync the root once → the whole environment comes up)Why: the root is an ordinary Application whose path points at a directory full of child Application YAMLs. directory.recurse tells ArgoCD to pick up every manifest under that path. Commit a new child Application file and the root deploys it on the next sync — adding an app becomes a git commit.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: root
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/myorg/gitops
path: apps # a folder of child Application manifests
targetRevision: HEAD
directory:
recurse: true
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true