Managing a cloud native infrastructure at scale is no longer just about deploying single applications – it’s about organizing environments, defining clear boundaries and keeping everything version-controlled, consistent, automated and easily managed within a simple and clear lifecycle process. This is where GitOps practices – tools like ArgoCD – truly shine.
One of ArgoCD’s most powerful patterns is called App of Apps – a design where a single parent ArgoCD Application manages and deploys multiple child ArgoCD Applications. It brings order to potentially chaotic deployments, improves observability and aligns perfectly with GitOps methodologies.
In this article, we’ll explore the App of Apps pattern in ArgoCD, including its concept, structure, pros and cons, as well as a production-grade way to configure child applications via dedicated values files. You’ll learn how to build a reusable, scalable pattern by deploying two example applications:
- NGINX Ingress Controller
- Cert-Manager
Let’s dive in.
What Is the App of Apps Pattern in ArgoCD?
Concept
The App of Apps pattern is an ArgoCD deployment strategy where one central ArgoCD Application (the “parent”) is responsible for managing and deploying several other Applications (the “children”). Each child application corresponds to a logical unit (e.g., a microservice, controller, or platform component) and is fully managed by ArgoCD.
This enables a modular, hierarchical structure – especially useful in environments where infrastructure is composed of many separate but related components.
Real-World Analogy
Think of the parent app as a conductor of an orchestra. Each instrument (child app) has its own sheet music (Helm chart or manifest) but plays in harmony through coordination by the conductor.
| Environment | Suitability |
|---|---|
| Development | ✅ Great for modular test setups |
| Staging/UAT | ✅ Ideal for environment replication and control |
| Production | ✅ Yes — with clearly defined sync policies, health checks and RBAC |
Benefits
- ✅ Modular Management: Each application is independently versioned and controlled.
- ✅ Reusability: Easily clone environments by reapplying the App of Apps.
- ✅ Central Visibility: One view to manage all applications.
- ✅ GitOps-Driven: Every change is tracked via Git, allowing for auditability and rollback.
Drawbacks
- ⚠️ Complexity Overhead: Initial learning curve and additional manifests.
- ⚠️ Drift Risks: Improper sync policies may result in applications going out of sync.
- ⚠️ Too Many Levels: Avoid deeply nested Apps of Apps, which can lead to confusion and debugging difficulty.
Prerequisites
Before proceeding, ensure you have the following:
- A running Kubernetes cluster.
- ArgoCD installed and configured in your cluster.
- kubectl and helm installed on your local machine.
- A Git repository to store your ArgoCD application manifests.
Step 1: Create Directory Structure
Let’s build a structure where we have a main app of apps YAML definition. I store it only as a reference as I will create that main app manually in ArgoCD. Each child application uses a dedicated Helm Chart with values.yaml file for configuration. Apps folder will keep all my applications defined as separate applications in ArgoCD. For reference you can refer to my repository URL: https://github.com/mariano-italiano/argocd-apps.git.
argocd-apps/
app-of-apps.yaml # ← Plain YAML (parent) defined in ArgoCD
charts/
nginx-ingress/
Chart.yaml
templates/
all manifests (Service, Deployment, etc.)
values.yaml
cert-manager/
Chart.yaml
templates/
all manifests (CRDs, Webhooks, etc.)
values.yaml
apps/
nginx-ingress.yaml # ← ArgoCD Application manifest
cert-manager.yaml # ← ArgoCD Application manifestStep 2: Define Child Applications
Once you have created the structure, you need to create the manifests for the child applications. Each Application points to the Helm chart in our Git repo. In my case, as mentioned above, I will create NGINX Ingress as well as Cert-Manager applications. Here you have both files:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: nginx-ingress
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/mariano-italiano/argocd-apps
targetRevision: HEAD
path: charts/nginx-ingress
helm:
valueFiles:
- values.yaml
destination:
server: https://kubernetes.default.svc
namespace: ingress-nginx
syncPolicy:
automated:
prune: true
selfHeal: true
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: cert-manager
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/mariano-italiano/argocd-apps
targetRevision: HEAD
path: charts/cert-manager
helm:
valueFiles:
- values.yaml
destination:
server: https://kubernetes.default.svc
namespace: cert-manager
syncPolicy:
automated:
prune: true
selfHeal: trueStep 3: Define the Parent App (App of Apps)
Let’s create the main app now. Login to ArgoCD and click on the Create Application button. Next, click on Edit as YAML on the right hand site and paste a main app with the following content:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-of-apps
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/mariano-italiano/argocd-apps
targetRevision: HEAD
path: apps
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated: nullClick Save and then Create on top to create the main application.
Once you have done that, you should have a similar state as the one presented in the picture below.
It is ok to have “OutOfSync” status as we intentionally chosen Manual sync policy in the definition. This is a safe option and gives you full control of everything is deployed or updated in the cluster.
Click on this item and navigate inside the apps. You will see the definitions of the two applications that are missing. This is exactly the mirror of our apps directory. Two applications that are missing from our cluster.
Click Sync button and then select all out-of-sync applications and finally click Synchronize.
The missing applications should start a creation process. In a few seconds you should see that the applications are synced and two additional items have been created.
Step 4: Verify the Deployment
Just to double check all is set and deployed fine, login to your Kubernetes cluster and validate all applications.
$ kubectl get all -n ingress-nginx
$ kubectl get all -n cert-manager
All looks good, the application’s pods are running and the final check is done.
Conclusion
The App of Apps pattern in ArgoCD is a production-ready, scalable and modular approach to managing multi-component Kubernetes environments. By structuring your deployments this way and using dedicated values.yaml files, you gain flexibility, reusability and clarity across environments. You can monitor any changes in YAML files that are stored in Git and track all changes made into them. It’s an ideal solution for platform teams, GitOps advocates and anyone managing more than one service in Kubernetes.