GitOps in Production: 10 Best Practices We Swear By

GitOps turns Git into the single source of truth for your infrastructure. The promise is seductive. The execution is where most teams stumble.

Here are the ten practices that separate GitOps that works from GitOps that is just another YAML dumpster.

1. Git is the only way to change anything

No manual kubectl, no click-ops in the console, no emergency SSH. If it isn't in Git, it doesn't exist.

2. Small, reviewable changes

A thousand-line PR is a deployment incident waiting to happen. Batch Helm charts and keep diffs tiny.

3. One app of record

Pick ArgoCD or Flux and standardize. Multiple GitOps controllers multiply your failure modes.

4. Secrets are never in Git

Use SOPS with age keys, or external secrets operators backed by Vault or cloud KMS. Encrypted at rest, decrypted at the edge.

5. Environments as a promotion path

dev → staging → prod is a series of merge requests, not scripts. Promote by merging, roll back by reverting.

6. Progressive delivery is a feature

Start with canary, then blue/green, then automated rollback. Argo Rollouts and Flagger make this boring — in a good way.

7. Healthy sync means healthy apps

Watch sync status, health status, and drift. Alert on drift, not just on failures — drift is the early warning signal.

8. Automated drift correction

Let the operator reconcile drift. Fighting the controller by hand is how drift becomes permanent.

9. Test your manifests

Validate Helm charts, schema-check CRDs, and run dry-runs in CI. A bad render should fail in CI, not in production.

10. Observability for GitOps itself

Metrics: sync duration, failures, drift, rollback rate. If you can't see it, you can't trust it.

The result

When GitOps is done right, deployment becomes the safest change you make all week. And that is the entire point.