What Is App Of Apps

In the previous module, we hardened container security contexts, configured compliance parameters, disabled default admin accounts, and verified security controls. With authentication and security clear, we will now start Module 10: App of Apps Pattern, beginning with What is App of Apps.

Managing hundreds of microservices manually by writing separate Application manifests inside ArgoCD is unmanageable. The App of Apps pattern solves this by defining a single "root" Application that tracks a Git directory containing other Application manifests, allowing you to bootstrap entire clusters declaratively.

In this guide, we will analyze bootstrapping design patterns, cluster declaration models, and multi-app control flows.

1. The Bootstrapping Design Pattern

The App of Apps pattern leverages the recursive reconciliation capabilities of ArgoCD. You configure a single root application to track a folder. Inside that folder, you store other Application manifests that point to your actual microservices workloads (e.g., payment API, frontend portal, databases):

               App of Apps Decoupled Architecture
┌────────────────────────────────────────────────────────┐
│  Root Application (Tracks Git: /apps-directory)        │
├────────────────────────────────────────────────────────┤
│  Matches and deploys child Application manifests:      │
│  ├── child-app-1 (Tracks Git: /payment-api)            │
│  ├── child-app-2 (Tracks Git: /frontend-portal)        │
│  └── child-app-3 (Tracks Git: /postgres-database)      │
├────────────────────────────────────────────────────────┤
│  Result: Single entry point bootstraps all services    │
└────────────────────────────────────────────────────────┘

1. Root Creation: You apply the root Application manifest manually or during cluster initialization.
2. Directory Sync: ArgoCD syncs the root app, pulling the child Application manifests from the /apps-directory folder.
3. Child Reconciliation: The controller registers the child applications. Each child application then syncs its own Git source paths, deploying the target microservice workloads.

2. Advantages of the App of Apps Pattern

By organizing your applications under a single root parent:

• One-Step Bootstrapping: You can initialize a new cluster from scratch (including logging, service meshes, databases, and microservices) by applying a single root manifest.
• Declarative Team Spaces: Teams can request new applications or workspaces by simply committing a new Application manifest file to the root directory in Git, bypassing manual console configurations.
• Cascading Deletions: Deleting the root application automatically cleans up all child applications and their cluster resources, simplifying lifecycle management.

3. Operational Best Practices: Bootstrapping

• Isolate the root application: Define the root application inside a secure administrative project (e.g., the default or infrastructure project) to prevent tenant access.
• Enforce sync wave ordering: Assign lower sync wave priorities (e.g., -5 or -10) to critical cluster components (such as Custom Resource Definitions or namespaces) so they deploy before child workloads start.
• Use automated pruning: Enable prune: true on both root and child applications to ensure resources are deleted from the cluster automatically when removed from Git.

4. Bootstrapping Models Comparison Summary

In this section, we analyzed the bootstrapping design patterns of the App of Apps pattern, reviewed architecture maps, and outlined operational advantages.

Now we will transition to App of Apps structures. In the next guide, we will cover how to design folders and repository layouts to support parent-child deployment patterns.