GitOps

Git as the source of truth for infrastructure and applications, the pull model, and reconciliation loops.

Overview

Git as the source of truth

GitOps is a deployment philosophy: Git holds the desired state, and agents continuously reconcile actual state to match it. Weaveworks coined it in 2017, and Kubernetes shops adopted it widely.

The four principles (gitops.tech)

1 — Declarative — System state described declaratively (YAML, HCL), not imperative scripts
2 — Versioned and immutable — Desired state in Git: full audit trail, rollback via revert
3 — Pulled automatically — Agents in the cluster pull from Git; no external CD pushes
4 — Continuously reconciled — Agents constantly compare actual with desired and correct drift

Pull vs push

Credentials — CI/CD holds production credentials; compromise means production compromise — Never leave the cluster
View of state — No view of what's actually deployed; failed pushes leave inconsistent state — Continuous view of actual state; drift corrected
Audit — Scattered — Every change is a commit; git log is the deploy history

Tools

Argo CD (CNCF) — The most popular. Web UI with sync status, diffs, history; multi-cluster; extensive RBAC
Flux (CNCF) — Pioneered GitOps. Lightweight; native Helm and Kustomize; v2 added multi-tenancy improvements

Both watch Git repos, pull on a schedule (typically every 1-5 minutes), apply through the Kubernetes API, detect and report drift, and either auto-correct or alert.

The canonical repository structure

Each cluster runs an Argo CD or Flux installation watching its path. Promotion (dev, then staging, then prod) is a Git operation: bump the image tag in that environment's overlay.

With progressive delivery

GitOps plus Argo Rollouts (or Flagger) is the standard 2026 stack.

Git — Holds the desired image version
Argo CD — Pulls and deploys to the cluster
Argo Rollouts / Flagger — Canary, progressive rollout, SLO-gated rollback
Outcome — A successful rollout needs no Git change; on rollback, Argo Rollouts reverts and Argo CD won't re-apply unless Git changes

Where it shines and where it struggles

Multi-cluster, multi-environment: central Git, per-cluster agents — Stateful operations (DB migrations, one-time jobs): imperative ops fit awkwardly
Auditability: every change is a commit — Secrets: Git isn't a secrets store; use Sealed Secrets, External Secrets, Vault
Rollback: revert the commit, plus drift detection and correction — Very large monorepos: Argo CD struggles; sometimes split them

> [!NOTE] Crossplane plus GitOps makes everything a Kubernetes resource managed by Git, even RDS and S3, reconciled by Argo CD. Powerful, but more complex than Terraform for infra and Kubernetes for apps.

Key concepts

GitOps four principles: Declarative + Versioned & Immutable + Pulled Automatically + Continuously Reconciled. Coined by Weaveworks.
Pull model: Agent inside cluster watches Git; applies changes. Opposite of push (external CI/CD does kubectl apply).
Argo CD: CNCF GitOps tool with Web UI. Multi-cluster, RBAC, sync status, diff view. Most popular GitOps in 2026.
Flux: CNCF GitOps tool. Lightweight; native Helm + Kustomize. v2 has multi-tenancy.
Drift correction: Agents continuously compare actual vs desired; either auto-correct or alert. Eliminates "someone clicked in the cluster" problem.
Promotion via Git: dev → staging → prod is a Git operation: change the image tag. PRs review the change.

When to use it

Multi-cluster Kubernetes deployments
Auditability / compliance requirements — Git log as deploy log
Drift-prone environments — continuous reconciliation prevents surprise
Teams transitioning from manual deploys to automation — GitOps + PR-based reviews

Interview questions

What is GitOps and why does it matter?
Argo CD vs Flux — how do you choose?
How do GitOps and progressive delivery fit together?