GitOps at Scale: ArgoCD Patterns for Enterprise Kubernetes with 100+ Microservices

GitOps with ArgoCD is conceptually simple: your Git repository is the source of truth for cluster state. ArgoCD watches the repository and reconciles. Push a change, see it deployed. But what works beautifully for 10 services becomes unwieldy at 100+. Repository structure decisions that seemed harmless at small scale create operational nightmares. Here are the patterns that work at enterprise scale.

Repository Strategy

The first question: mono-repo or multi-repo? The answer is neither — use a layered approach:

• Platform repo — Cluster-level resources: namespaces, RBAC, network policies, monitoring configuration. Owned by the platform team.
• App-of-apps repo — ApplicationSet definitions that generate ArgoCD Applications. Maps team → namespace → services.
• Service repos — Each microservice has its own repo with application code, Dockerfile, and Kustomize overlays. CI pipeline updates image tags here.

This separation means application developers never touch cluster configuration, and platform engineers don't need to review application deployments. Changes flow through appropriate approval chains.

ApplicationSet Patterns

ApplicationSet is ArgoCD's answer to managing hundreds of Applications. Key patterns:

• Git directory generator — Discover services by directory structure. Add a new directory, get a new Application automatically.
• Matrix generator — Cross-product of clusters × services. Deploy the same services across dev/staging/prod clusters.
• Pull request generator — Create ephemeral environments for pull requests. Destroy on merge.
• Cluster generator — Automatically deploy platform services to every registered cluster.

Multi-Cluster Management

Enterprise environments have multiple clusters: dev, staging, production, and possibly per-region production clusters. ArgoCD can manage them all from a single control plane:

• Register each cluster via ArgoCD CLI or declarative cluster secrets
• Use ApplicationSets with cluster selectors to target deployments
• Implement progressive delivery: dev → staging → production with promotion gates
• Deploy ArgoCD itself via GitOps (yes, ArgoCD can manage itself)

RBAC at Scale

ArgoCD's RBAC system maps SSO groups to ArgoCD roles. At enterprise scale:

• Project isolation — Each team gets an ArgoCD Project that restricts which repos, clusters, and namespaces they can deploy to
• Read-only by default — Most users need visibility, not deploy access. Give read access broadly, write access narrowly.
• Sync windows — Restrict production deployments to business hours or specific maintenance windows
• SSO integration — Integrate with your IdP (Keycloak, Okta). Group membership drives access. No local ArgoCD accounts.

Secret Management

Secrets don't belong in Git — even encrypted. Use ArgoCD with external secret management:

• External Secrets Operator — Syncs secrets from Vault, AWS Secrets Manager, or Azure Key Vault into Kubernetes secrets
• Sealed Secrets — Encrypt secrets that can only be decrypted by the cluster. Acceptable for simple use cases.
• Vault Injector — Injects secrets directly into pod environment or files at runtime. Secrets never stored as Kubernetes objects.

Drift Detection and Remediation

At scale, drift is inevitable. Someone runs kubectl edit. A CRD controller modifies a resource. ArgoCD's self-heal mode automatically reverts drift, but be careful: some resources are managed by multiple controllers. Use ignore-differences annotations for fields managed by external controllers (like HPA-managed replica counts).

What Open Empower Delivers

We design GitOps architectures for enterprise Kubernetes: repository structure, ApplicationSet patterns, multi-cluster management, RBAC, and secret management. ArgoCD that scales from day one to hundreds of services.