Plenty of technical ideas survive on vocabulary. GitOps does not need it. In plain terms: your team writes down exactly how its systems should look, keeps that description in a store that preserves every revision, and lets software inside the platform fetch the description and keep the real system matched to it. That is the entire idea. The rest of this article walks through what actually happens in practice — the loop the software runs, why the direction of travel matters, the boundaries people most often blur, and the worries that surface in every team’s first year. No prior operations background is assumed, and nothing here depends on a particular vendor, because the idea, like most good clinical practice, is older than its tooling.
What GitOps is, in four verbs
Every reconciliation cycle, however sophisticated the product, reduces to the same four moves:
- Observe. The agent reads its stored description of what the system should be.
- Compare. It inspects the running platform and works out the difference between that description and reality.
- Act. According to rules agreed in advance, it applies the missing pieces, removes what no longer belongs, or rolls back what does not match.
- Report. It publishes the outcome — healthy, drifting, or failed — where the whole team can see it.
Then it does all four again. Nobody demands split-second timing; a check every few minutes is genuinely continuous, in the sense that matters, which is that unreviewed changes do not get to live long. The rhythm is closer to ward observations than to emergency response: frequent, systematic, and reassuring mostly because it never skips a round.
A physiotherapy analogy that actually holds up
Consider recovery after knee surgery. The discharge pack states the programme: which exercises, at what frequency, progressing by which milestones. The physiotherapist then sees the patient regularly, measures progress against the written programme, corrects what has drifted, and records the visit. The pack is the declared state. The physio is the reconciler. Now remove the physio and leave the pack in a drawer — nothing improves, and nobody can say the programme failed, because the programme was never executed. That is the difference between storing configuration and operating on it, and it is the single most common half-adoption in this field. The written plan earns nothing until something disciplined checks reality against it, over and over, and gently forces the two back together.
“Declarative” without the jaw-cracking definition
Engineers say a GitOps description is declarative, and the word intimidates people for no good reason. A declarative description states the destination; it does not narrate the journey. Compare a prescription with a procedure note. The prescription states the target — this drug, this dose, this duration — and anyone competent can fill it. The procedure note narrates each step as it happened. Most traditional deployment scripts are procedure notes: step one, copy the files; step two, restart the service; step three, hope. A declared state is the prescription. It says the service runs this version with these settings behind that routing rule, and it says nothing about which commands got there — which is exactly why the same description can be checked, repeated, and rebuilt by different hands on different days with the same result.
Why GitOps pulls instead of pushes
Direction matters more than it sounds. In the older arrangement, a build server holds production credentials and pushes changes into the platform — meaning the keys to the ward sit in a building anyone can theoretically reach, and every pipeline misconfiguration becomes a door. In the GitOps arrangement, the platform sends out for its own instructions: an agent inside the boundary reads the store and works outward from there, needing nothing beyond the ability to read. Credentials stay home. The pipeline never touches production; it only publishes new descriptions for the agent to collect. A webhook can hurry things along — think of it as a text reminder asking the agent to attend its next check early — but the delivery itself is always the agent’s own trip, on its own schedule, through its own door.
Three boundaries people keep blurring
Each of these deserves one clean sentence, so here are three. First, GitOps is not the same thing as infrastructure-as-code: the code describes state in a particular language, while GitOps is the operating routine that keeps reality matched to it — the vocabulary and the daily practice of speaking it. Second, it is not a release strategy: deciding whether a new version reaches ten percent of users or all of them is a different discipline that layers neatly on top, the way a rehabilitation protocol differs from the surgery schedule that precedes it. Third, it is not a place for data: the store holds structure — what should exist, at which versions — while records, database contents, and everything your users actually created stay in proper storage with proper backups, where auditors and recovery plans expect to find them.
Worries worth settling in the first year
Three questions come up in almost every early conversation, and each has a calm answer. What happens if the agent stops? Nothing dramatic — the system keeps running as it is, it simply stops self-correcting until the agent returns, which is why teams watch the reconciler’s own health the way they watch any other always-on component. What if the store becomes unreachable? The agents keep enforcing the last good description they read; change propagation pauses, production does not. What if two teams disagree about what production should be? Under this model that argument happens in one place — the store — before either change ships, which is a considerable improvement on the historical method of discovering the disagreement inside the platform at midnight. The pattern behind all three answers is the same: GitOps trades silent, unrecorded flexibility for loud, reviewable agreement, and almost everyone who lives with the trade decides it was underpriced.
The tools you will actually meet
Two names dominate. Argo CD presents a central service with an interface, permissions, and application templates, which suits organisations that want one visible control room. Flux distributes the work — a small agent on each cluster, doing its own fetching and correcting on local schedules, which suits teams who prefer fewer central parts. Both read the store, both reconcile, both report status, and choosing between them is an architecture decision rather than an ideology. A knowledgeable human summary of the field, with the history and the edge cases filled in, sits in a GitOps primer from xOps School, which is the natural second read after this one.
What a healthy adoption looks like six months in
You can diagnose an adopted team without reading a single config file. Changes reach production as reviewed requests, and nobody remembers the last time someone logged into a server to fix something by hand. When an incident review is held, the discussion quotes the store: this definition, this commit, this decision record. New starters spend their first week reading descriptions of systems rather than shadowing veterans, because the descriptions are actually true. The audit question — who changed what, when, and who agreed — is answered by exporting a report rather than reconstructing history from memory and chat logs. And releases have become unremarkable. Teams that expected excitement report a mild anticlimax instead, which is precisely what success looks like in operations: the absence of drama, purchased in advance through structure.
The habit this site’s readers already understand
Good knee care proceeds by systematic evaluation: history, examination, imaging in proportion, then a written plan that everyone can read — the approach described in how clinicians evaluate knee pain and set treatment plans. Strip the clinical vocabulary and GitOps is that same discipline aimed at servers: observe honestly, compare against a written standard, act proportionately, record the outcome. Readers curious about the wider territory will find the surrounding structure in this site’s piece on the unified architecture of XOps, and a practical view of putting such ideas to work in streamlining software and cloud operations. Write the destination clearly. Send a disciplined checker around on a schedule. Keep the record where everyone can read it. Very little else in modern operations is genuinely more complicated than that.