What It Does
GitOps is an operational framework where the complete desired state of a system (application configuration, Kubernetes manifests, Helm charts, Terraform plans) is stored in Git and treated as the authoritative source of truth. A software agent (typically Argo CD or Flux) continuously monitors both the live cluster state and the Git state, and automatically reconciles any drift. Deployments happen by committing changes to Git; the reconciliation loop applies them without manual kubectl or Terraform applies.
The term was coined by Alexis Richardson (Weaveworks CEO) in 2017. It became the de facto deployment pattern for Kubernetes-native organizations. The OpenGitOps project (CNCF) published a vendor-neutral specification (v1.0, 2022) defining four principles: declarative state, versioned and immutable history, automatically pulled software agents, and continuously reconciled desired and actual state.
Key Features
- Declarative infrastructure: All resources described in Git as YAML/JSON/HCL; no imperative scripts or live cluster mutations outside of Git commits.
- Automated reconciliation: Argo CD or Flux controller watches Git repo and cluster state; applies diffs automatically on commit or on scheduled sync.
- Drift detection and alerting: Detects when live cluster state diverges from Git (e.g., manual kubectl edit) and alerts or auto-corrects.
- Pull-based deployment model: CI pushes images to a registry; GitOps controller pulls desired state from Git. Cluster credentials do not live in CI systems.
- Multi-cluster and multi-tenant support: Argo CD ApplicationSets and Flux’s Kustomization overlays support managing hundreds of clusters from a single control plane.
- Rollback via git revert: Any deployment can be rolled back by reverting the Git commit; full audit history is in the version control system.
- Secret management integration: GitOps controllers integrate with sealed secrets, External Secrets Operator, Vault, or AWS Secrets Manager to avoid storing plaintext secrets in Git.
Use Cases
- Kubernetes cluster fleet management: Platform teams managing 10+ clusters across environments (dev/staging/prod) or regions using a single GitOps repository hierarchy.
- Compliance and audit requirements: Financial services or healthcare teams needing an immutable audit trail of every infrastructure change, who changed it, and when.
- Self-service developer platforms: Internal developer portals where developers submit a PR to provision a new service or environment; GitOps automation handles the actual provisioning.
- Disaster recovery: Re-applying a Git repository to a new cluster can rebuild infrastructure deterministically after a disaster; eliminates reliance on manual runbooks.
Adoption Level Analysis
Small teams (<20 engineers): Partial fit. GitOps adds tooling overhead (Argo CD, repository structure) that can be disproportionate for 1–3 services. Direct CI-driven kubectl or Helm deploys are often simpler. Worth adopting when the team grows beyond 3–4 Kubernetes namespaces.
Medium orgs (20–200 engineers): Strong fit. Multiple teams deploying to shared clusters create drift and conflict risk that GitOps reconciliation solves. Argo CD is the standard choice; Flux is an alternative with better multi-tenancy for strict namespace isolation. One platform engineer can manage the GitOps control plane.
Enterprise (200+ engineers): Adopted standard. Almost all enterprise Kubernetes shops running at this scale have adopted GitOps. The debate is tooling (Argo CD vs Flux vs Harness GitOps) and repository structure (monorepo vs polyrepo), not whether to use the pattern.
Alternatives
| Alternative | Key Difference | Prefer when… |
|---|---|---|
| Push-based CD (Jenkins, GitHub Actions) | CI pipeline pushes directly to cluster using credentials | Simple setups, non-Kubernetes targets, teams without K8s expertise |
| Pulumi / Terraform + CI | Imperative or declarative IaC run from CI, not reconciliation loop | Mixed cloud/K8s environments, infrastructure beyond K8s |
| Helm + ArgoCD | GitOps with Helm chart values as the Git artifact | Prefer Helm’s templating over raw manifests or Kustomize |
Evidence & Sources
- OpenGitOps Specification v1.0 (CNCF)
- Argo CD Documentation — CNCF graduated project; most-adopted GitOps controller
- Flux CD Documentation — CNCF graduated project; strong multi-tenancy model
- Weaveworks: “GitOps” origin post by Alexis Richardson (2017)
- CNCF GitOps Working Group
Notes & Caveats
- Secrets are not solved by GitOps: Git-stored secrets are a recurring operational mistake. Teams must choose an external secrets pattern (External Secrets Operator, Sealed Secrets, Vault) before adopting GitOps in production. This adds a meaningful operational dependency.
- Repository structure decisions are hard to change: Monorepo vs polyrepo, environment branching vs directory-per-environment, and cluster-per-app vs app-per-cluster are architectural decisions with high migration cost. Getting these wrong creates messy overlays and merge conflicts.
- Slow feedback for developers: Developers commit code and wait for a GitOps sync cycle (default: 3 minutes in Argo CD) to see their change applied. Local development workflows (telepresence, skaffold) are needed alongside GitOps to maintain developer velocity.
- Not a replacement for CI: GitOps handles the CD side; CI (build, test, image push) remains separate. The GitOps deployment boundary is “image tag or Helm values change in Git,” not “source code change.” Teams sometimes conflate GitOps and CI, leading to architectural confusion.
- Harness GitOps gap: User reviews specifically note that Harness’s GitOps implementation lacks a proper reconciliation loop compared to upstream Argo CD, making it a weaker choice for strict GitOps adoption versus running Argo CD directly.