28 questions foundUse separate roots per environment, each pointing at environment-specific child configs (overlays/values pinned to that env's revisions). Shared bases keep consistency while overlays capture differences, so promotion is a PR updating the next environment's config.Real-world example dev/staging/prod each have a root pointing at their overlay directory, differing only in tags and sizes.Multi-cluster GitOps Principles App of AppsCan the parent app itself be managed by GitOps?
Intermediate Yes—commit the root Application manifest to Git and either apply it once to bootstrap or have another ArgoCD/root manage it. Keeping the root in Git means even the bootstrap definition is versioned and reviewable, closing the GitOps loop.Real-world example The root manifest lives in Git so changes to which children exist go through pull requests too.GitOps Principles Applications App of AppsApplicationSets (generator-driven), Flux Kustomizations, or Helm umbrella charts can manage many apps. ApplicationSets are the native ArgoCD evolution for dynamic fleets; umbrella charts bundle subcharts but couple them tightly. Choice depends on how dynamic and independent the apps need to be.Real-world example The team compares an ApplicationSet against a Helm umbrella chart before choosing generators for flexibility.Applications Multi-cluster App of AppsWith prune enabled on the root, removing a child Application manifest from the watched directory prunes that child app (and, if its own finalizer is set, its resources). Without prune, the child remains. So directory contents plus prune settings control the app set.Real-world example Removing service-a.yaml from the apps directory prunes the service-a Application on the next root sync.Applications Sync & Health App of AppsCombine App of Apps (or ApplicationSets) with AppProjects and RBAC: each team's child apps belong to their project, which restricts destinations and sources, and RBAC scopes their permissions to that project. Teams manage their apps via PRs without affecting others.Real-world example Team B owns its child apps within the team-b project, unable to deploy outside its namespaces or touch team A's apps.RBAC Applications App of AppsA root app per cluster (or an ApplicationSet cluster generator producing roots) can bootstrap each cluster's platform and workloads. Applying the appropriate root to ArgoCD provisions that cluster's full app set, enabling consistent, reproducible multi-cluster setup.Real-world example Each new cluster gets its platform by applying that cluster's root app, which pulls in the standard component set.Multi-cluster GitOps Principles App of AppsThe ArgoCD UI shows the root app with its child Applications as resources, so you see aggregated status. Because children are Applications, their individual sync/health roll up, letting you spot which environment component is failing from the root view.Real-world example The root app's tree view flags that only the monitoring child is Degraded, pinpointing the issue fast.Sync & Health Applications App of AppsSince the root and children are in Git, roll back the set by reverting the relevant commits (e.g., the parent config or child revisions) and letting ArgoCD reconcile. This versions the entire environment composition, enabling coordinated rollback of the app set, not just one app.Real-world example A problematic platform change is undone by reverting the parent repo commit, restoring the previous child set.GitOps Principles Applications App of Apps
Showing 21–28 of 28