GitOps
Also known as: Git-based operations
GitOps is a way of running systems in which the desired state of infrastructure and applications is stored in a Git repository, and automated agents continuously make the live environment match it.
To change production, you change Git. While it sounds like simply using version control for configuration, the real shift is that the agent pulls changes and corrects drift automatically, so Git becomes the single source of truth.
GitOps, explained at three levels
At home
Imagine a thermostat: you set the temperature you want, and it keeps adjusting the heat to match. GitOps works the same way for software. You write down how the system should look in Git, and a tool keeps adjusting the real system to match.
At work
With GitOps, teams deploy changes by updating files in a Git repository and getting them reviewed. Automation applies the change. That gives you a full history of who changed what, and rolling back is as simple as reverting a commit.
At home
In traditional deployments, a pipeline 'pushes' changes to servers. In GitOps, an agent running inside the environment 'pulls' the desired state from Git and applies it. If someone changes something manually, the agent notices the difference and puts it back.
At work
GitOps is most common with Kubernetes, using tools such as Argo CD or Flux. Repositories hold manifests, Helm charts, or Kustomize overlays for each environment. Promotion between environments happens through pull requests, which fits neatly with code review and audit requirements.
At home
The reconciliation loop is the heart of GitOps: compare the desired state with the actual state, then act on the difference, repeatedly. In my opinion, that idea, borrowed from Kubernetes itself, is more robust than one-off deploy scripts, because the system keeps healing instead of drifting.
At work
Challenges include secrets (which shouldn't sit in Git in plain text, so teams use sealed secrets or external secret stores), repository structure across many clusters, and handling database migrations that don't fit a declarative model. Security improves because CI systems no longer need production credentials, but the Git repository becomes a high-value target that needs strong branch protection.
Real-world examples
At home
Marcus runs a small home server cluster for his projects. He set up Flux so that every change lives in a Git repository. When he broke something at midnight, he reverted one commit and the cluster restored itself in a minute.
At work
Nadia is a DevOps lead at a healthcare software company that must prove who approved every production change. Moving to GitOps meant every deployment was a reviewed pull request, which turned a painful audit into a simple export of Git history.
How it compares
| feature | GitOps | Push-based CI/CD |
|---|---|---|
| How changes reach production | Agent pulls desired state from Git | Pipeline pushes changes to servers |
| Drift correction | Automatic and continuous | Only on the next deployment |
| Production credentials | Stay inside the cluster | Held by the CI system |
| Rollback | Revert a commit | Rerun an older pipeline |
GitOps makes Git the source of truth and lets the environment correct itself.
For analysts
For regulated teams, GitOps can turn change management from paperwork into a by-product of normal work. I'd present it to auditors as evidence of control, since every change is reviewed, attributed, and reversible.
History & origin
The term was coined in 2017 by Alexis Richardson of Weaveworks, which built the Flux tool for Kubernetes. Intuit created Argo CD around 2018, and both projects joined the Cloud Native Computing Foundation and later graduated. In 2021, the OpenGitOps project published four principles: declarative, versioned and immutable, pulled automatically, and continuously reconciled. Weaveworks itself shut down in early 2024, but Flux continued as a community project, and GitOps had become a standard pattern for Kubernetes deployments. In my view, GitOps' biggest benefit isn't automation. It's that every production change has an author, a review, and an undo button.