How GitOps Works
IntermediateGitOps is a way to deploy and manage infrastructure where Git is the single source of truth for the desired state. You describe what should be running (usually as Kubernetes manifests) in a Git repository, and an automated controller continuously compares the live system to Git and reconciles any difference. Deployments become git commits, rollbacks become git reverts, and the cluster is always kept in sync with the repository — auditable, automated, and self-healing.
Think of a thermostat for your infrastructure
A thermostat has a desired temperature (the setting) and continuously nudges the room to match it — if a window is opened and the room cools, it heats back up automatically. GitOps makes Git the thermostat setting: it declares the desired state of your system. A controller is the thermostat, constantly checking the real system against Git and correcting any drift. Change the setting (commit to Git) and the system adjusts; nobody adjusts the room by hand.
Step by Step
Key Concepts
Git as Source of Truth
The entire desired state of the system is declared in Git. Every change is a commit, giving version history, code review, and a complete audit trail for infrastructure and deployments.
Reconciliation Loop
A controller continuously compares live state to the declared state in Git and corrects any difference, making the system self-healing and always convergent toward Git.
Pull vs Push Deployment
In push, a CI pipeline pushes changes into the cluster (needs cluster credentials). In GitOps pull, an in-cluster agent pulls from Git, keeping credentials inside the cluster and improving security.
Drift Detection
Because the controller constantly compares reality to Git, any manual or accidental change (drift) is detected and can be automatically reverted, keeping the environment consistent with its definition.
Key Facts
- In GitOps, a deployment is a git merge and a rollback is a git revert — with the full review, history, and auditability of version control.
- The pull model (controller pulls from Git) keeps deployment credentials inside the cluster, unlike push pipelines that need external access.
- Argo CD and Flux are the two dominant GitOps controllers for Kubernetes; both continuously reconcile clusters to Git.
Real-World Applications
Auditable, self-healing deployments
Every production change is a reviewed pull request; the GitOps controller applies it and, if anyone hand-edits the cluster, reverts the drift automatically — so the running system always matches the repository.
Fast, safe rollbacks
When a release causes issues, reverting the offending commit returns the cluster to the last good state within the reconciliation interval, with a clear record of what changed and when.
Frequently Asked Questions
What is GitOps?
GitOps is an operational model where Git is the single source of truth for the desired state of your infrastructure and applications. You declare what should be running in a Git repository, and an automated controller continuously reconciles the live system to match Git. Deployments become commits and rollbacks become reverts, giving you version control, code review, and auditability for operations.
What is the reconciliation loop in GitOps?
It is the continuous process by which a GitOps controller compares the actual state of the system against the desired state declared in Git, and applies whatever changes are needed to make them match. This runs constantly, so the system self-heals: if the cluster drifts from Git — through a manual change or a failure — the controller automatically brings it back in line with the repository.
What is the difference between push and pull deployment in GitOps?
In a push model, an external CI/CD pipeline pushes changes into the cluster, which requires giving that pipeline cluster credentials. In the GitOps pull model, an agent running inside the cluster pulls the desired state from Git and applies it. The pull approach keeps deployment credentials inside the cluster rather than exposing them to external systems, reducing the attack surface — one reason GitOps favours it.
What tools are used for GitOps?
The two most popular GitOps controllers for Kubernetes are Argo CD and Flux. Both run inside the cluster, watch a Git repository for the desired state, and continuously reconcile the cluster to match it, including drift detection and automated syncing. They are typically paired with Kubernetes manifests, Kustomize, or Helm for defining the desired state in Git.