GitOps in Production: ArgoCD Patterns That Actually Work
Practical ArgoCD configuration patterns for multi-environment deployments, with real-world examples from production Kubernetes clusters.
GitOps in Production: ArgoCD Patterns That Actually Work
GitOps sounds simple in theory: Git is the source of truth, and your cluster continuously reconciles to match it. In practice, production deployments involve multiple environments, secrets management, promotion workflows, and the inevitable edge cases that tutorials never cover.
After running ArgoCD across five environments for 300+ microservices, here are the patterns that have proven reliable.
App of Apps vs ApplicationSet
The most common question when structuring ArgoCD is whether to use App of Apps or ApplicationSet. The answer depends on your team structure.
App of Apps works well when you have a small number of applications managed by a central platform team. You define a “root” Application that manages a set of child Application manifests.
ApplicationSet is better when you need to generate Applications dynamically — for example, one Application per team, or per environment, based on a set of parameters.
We use both: ApplicationSet to generate per-environment Application objects, and App of Apps within each environment for logical grouping.
Secrets Management Without GitOps Anti-Patterns
The most common GitOps mistake is committing secrets to Git — even encrypted ones raise questions about rotation and auditability.
The pattern we use:
- Secrets stored in AWS Secrets Manager or Azure Key Vault
- External Secrets Operator running in the cluster, syncing secrets into Kubernetes
Secretobjects - ArgoCD deploys the
ExternalSecretresource (not the actual secret value) - Developers never touch Kubernetes secrets directly
This keeps Git clean, maintains auditability, and integrates with your existing secrets rotation workflows.
Promotion Workflows
Promotion (moving an image from dev → staging → production) is where most GitOps setups get complicated.
Our approach uses image update automation for non-production environments and pull request-based promotion for production:
- Dev: ArgoCD Image Updater watches the registry and auto-commits new image tags
- Staging: Tagged releases auto-promote via a GitHub Actions workflow
- Production: A human opens a PR, it is reviewed, and merging triggers deployment
This gives speed in lower environments while maintaining control in production.
Health Checks and Sync Waves
ArgoCD’s sync waves let you control the order resources are applied. We use this for database migrations:
metadata:
annotations:
argocd.argoproj.io/sync-wave: "-1" # Run before app deployment
The migration Job runs first, and ArgoCD waits for it to complete successfully before proceeding to the application Deployment. This eliminates the class of “app started before migration ran” incidents.
Want to discuss GitOps architecture for your team? Get in touch.