Helm Chart Managed by ArgoCD # What We Built # A single reusable Helm chart at charts/backend-service/ shared by three services (svc1, svc2, svc3), all deployed into the dev namespace on Rancher Desktop. Environment-specific configuration lives outside the chart in environments/<env>/, one folder per environment. Each environment folder is self-contained - when a second cluster is added (e.g. minikube for staging), its ArgoCD instance points only at its own environment folder.
ApplicationSet - Auto-Discover Services from Git # What We Built # A eu-dev environment that runs on the same Rancher Desktop cluster as dev, deploying into namespace alpha-dev. The difference is in how ArgoCD Applications are created:
Environment How Applications are created Namespace dev One Application YAML per service, applied manually with kubectl dev eu-dev One ApplicationSet, applied once; services auto-discovered from values files alpha-dev Both use the same charts/backend-service/ Helm chart. dev is kept as a reference for the manual pattern.
App-of-Apps Bootstrap Pattern # What We Built # A root ArgoCD Application that watches environments/dev/apps/ and manages every Application manifest it finds there. A single kubectl apply bootstraps all services in the environment; after that, adding or removing a service is a git operation only.
How It Works # 1 2 3 4 5 6 7 8 9 kubectl apply -f environments/dev/bootstrap.yaml │ │ watches environments/dev/apps/ ▼ Application: root-dev │ ├── svc1.yaml → Application: svc1-dev → Deployment, Service, Ingress in ns: dev ├── svc2.yaml → Application: svc2-dev → Deployment, Service, Ingress in ns: dev └── svc3.yaml → Application: svc3-dev → Deployment, Service, Ingress in ns: dev ArgoCD manages Application objects the same way it manages any other Kubernetes resource. The child Applications are reconciled from git - if you delete environments/dev/apps/svc2.yaml, ArgoCD deletes svc2-dev (and its workloads, because prune: true).
App-of-Apps vs ApplicationSet - When to Use Which # The Core Difference # Both patterns answer the same question: how do I manage many ArgoCD Applications without manually applying each one? But they solve it at different levels.
App-of-Apps - a manually maintained parent Application that watches a directory of hand-written child Application manifests. You own every YAML.