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:

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.

Hierarchical applications graphic

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.

EnvironmentSuitability
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

Drawbacks

Prerequisites

Before proceeding, ensure you have the following:

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.

Indented code example

Step 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: true

Step 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: null

Click 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.

App-of-Apps Graphic

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.

Dashboard graphic

Click Sync button and then select all out-of-sync applications and finally click Synchronize

Dashboard graphic after clicking 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.

Healthy dashboard graphic
Image of application dashboard

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

Student Ubuntu code graphic
Student Ubuntu code graphic example

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.