GitOps on Amazon EKS with ArgoCD: A Reference Setup

GitOps is a simple idea with big payoffs: your Git repository is the single source of truth for what runs in your cluster, and an automated agent continuously makes the cluster match it. No more kubectl apply from a laptop, no more drift between what you think is deployed and what actually is. On Amazon EKS, ArgoCD is the most common way to put this into practice. Here is a reference setup.

Why GitOps

• Every change is a reviewed, auditable commit. Deployments go through pull requests, not manual steps.
• The cluster self-heals toward Git. If something drifts, the agent reconciles it back.
• Rollbacks are a git revert. Recovering a bad release is as simple as reverting a commit.
• Onboarding is easier. The repository shows exactly what is deployed and how.

Repository layout

A clean separation keeps things maintainable:

• One repository (or directory) for application source and its Helm chart or manifests.
• A separate config repository that declares what runs in each environment, referencing chart versions and image tags.

The config repo is what ArgoCD watches. Promoting a release from staging to production becomes a small, reviewable change to that repo.

Install ArgoCD on EKS

Install ArgoCD into its own namespace on the cluster. Put access behind your SSO provider and enforce RBAC so only the right people can sync or override. Treat ArgoCD itself as infrastructure as code so the install is reproducible.

Define applications and sync policy

An ArgoCD Application points at a path in the config repo and a destination namespace. Enable automated sync with self-heal and prune so the cluster tracks Git and removes resources that are deleted from it. Use sync waves when resources must come up in order, such as a database before the app that depends on it.

Handle secrets safely

Never commit plain secrets. The common patterns:

• Sealed Secrets, which encrypt secrets so only the cluster can decrypt them.
• The External Secrets Operator, which pulls values from AWS Secrets Manager at runtime.

Either keeps sensitive values out of Git while keeping the workflow declarative.

Progressive delivery

Once GitOps is in place, layer on safer releases. Argo Rollouts adds canary and blue-green strategies, shifting a small share of traffic to a new version and promoting it only if metrics stay healthy. Combined with good observability, this turns risky deploys into routine ones.

Common pitfalls

• Letting people run manual kubectl changes alongside GitOps, which creates the drift you were trying to eliminate.
• Putting everything in one giant application instead of splitting by service or team.
• Skipping RBAC, so anyone can sync anything.

The payoff

With ArgoCD on EKS, deployments become boring in the best way: reviewed, repeatable, and easy to reverse. That is the setup behind our client work delivering CI/CD with ArgoCD and Helm on EKS.

We build these platforms as an AWS Advanced Tier Partner. If you want GitOps running properly on your cluster, book a free audit, or read more about what GitOps is, ArgoCD vs Flux, and our Kubernetes and EKS work.