Ask five platform engineers what GitOps means and you will hear five answers that agree on the essentials and differ in the details. The essentials are these: the state you want — every deployment, every setting, every rule about what should exist — is recorded in a repository that preserves every revision, and a software agent continuously pulls that record and adjusts the live system until reality matches it. No engineer logs into production at midnight to nudge a file by hand. The repository is the plan, the agent is the executor, and convergence is a property of the system rather than a hope. The questions below come up again and again, and they are answered here with comparisons drawn from spaceflight, because few professions write things down, rehearse, and verify quite like the teams that fly spacecraft.
What does GitOps change about the working day?
Before the method is adopted, a person with server access makes changes directly: edit a configuration, restart a service, note it in a chat channel if anyone remembers. Afterward, the change itself becomes a proposal. It is written as a file, reviewed by a colleague, merged, and then carried out by the automation. Every modification ends up with an author, a reviewer, a timestamp, and a visible difference from the previous version. Several familiar frustrations quietly disappear:
- Hand-edited production files that nobody can later explain.
- Fixes applied at 2 a.m. that fixed the symptom and altered nothing on record.
- The recurring meeting question: who changed this, and when?
- Staging and production drifting apart until nobody trusts either.
Access to production stops being the qualification that matters. Writing a clear proposal, and reviewing someone else’s carefully, becomes the skill the system is built around.
Why do flight-control comparisons suit GitOps so well?
A satellite assigned to a fixed slot does not stay there through obedience. Gravitational irregularities and faint atmospheric drag pull it off station every day. Controllers do not respond by scolding the spacecraft; they declared the target orbit long ago, and they schedule periodic correction burns that bring it back. The declared orbit is the specification, the burns are reconciliation, and the ground team trusts the cycle because it was designed and rehearsed — much as a geostationary orbit holds its slot through constant small corrections rather than one grand gesture.
A satellite keeps its position because somebody declared the position and scheduled the corrections. Clusters behave the same way.
Reconciliation under GitOps is continuous in this sense: not instantaneous, but steady. An agent that checks every few minutes and converges each time qualifies. What disqualifies a setup is the absence of the loop — a system where reality can wander and nothing ever pulls it back.
What happens after a change is merged?
The sequence is short enough to memorize. A reviewed pull request lands in the repository. The agent notices — either because a webhook nudged it or because its scheduled poll came around — then it observes the live system, computes the difference between record and reality, and acts: apply what is new, prune what was removed, roll back what is wrong. Finally it reports, so the next reader sees a status rather than a mystery. Engineers who fly uncrewed missions will recognize the shape: a mission divided into clear phases, each with its own exit criteria, where no phase begins until the previous one has reported healthy. One boundary matters: the agent only touches what it has been told to watch. Everything outside its scope stays exactly as it was.
Is a pipeline job that runs kubectl apply the same thing?
No, and the distinction is worth a paragraph. A continuous-integration job still has real work to do — compiling, testing, packaging — and GitOps does not take any of that away. The difference is who delivers the result. A push job reaches into the cluster from outside and applies whatever the latest build produced, then goes away. The published OpenGitOps principles describe a different shape: the intended state is declared, the store holding it is versioned and immutable, software agents pull it themselves, and the matching process never stops. A one-shot job that pushes can satisfy at most two of those four. It neither pulls nor reconciles. It fires, and then the system is on its own until the next push.
Does GitOps only apply to Kubernetes?
The pattern grew up there, but the borders are wider. Declarative tooling can describe cloud resources — databases, queues, DNS entries — and reconcilers such as Crossplane or tofu-controller will pull those declarations into being the same way. The store itself does not even have to be Git: a container registry of the OCI flavour, or a bucket with versioning switched on, satisfies the requirement, which is why the phrase “Gitless GitOps” exists. What cannot be removed is the pair at the center: a declared state, and an agent that continuously reconciles the live system against it. Everything else is negotiable detail.
How does GitOps cope when someone edits production by hand?
The industry word is drift: reality leaving the recorded specification. Not all drift is mischief. An autoscaler raising a replica count, or a controller filling in a default field, both look like divergence yet serve a purpose — mature setups tolerate them explicitly by marking those fields ignored. Genuinely unauthorized edits are a different case. On the next pass the agent reverts them, unless a policy says otherwise. That word “policy” is doing real work, because sensible teams decide per resource: revert this one, tolerate that one, alert without acting on a third, and shield a fourth from pruning altogether — namespaces, persistent volume claims, and custom resource definitions usually land in that last group, since deleting them cascades.
Is GitOps a replacement for backups?
It is not, and confusing the two has ended badly for teams that learned it the expensive way. What a repository stores is intent: which versions should run, which rules should apply, what should exist at all. It does not hold database contents, object payloads, or the data sitting on persistent volumes — those live outside Git by design. When a storage failure destroys data, the repository can rebuild the structure, but only a backup can restore what filled it. The two systems answer different questions. One remembers what the system should look like; the other remembers what was actually in it. Careful operations keep both, test both, and never let either stand in for the other.
Where should a newcomer begin?
Start by reading a proper reference rather than a thread of hot takes — the Ops Atlas GitOps entry is a detailed place to anchor the vocabulary. Then pick one unimportant service, write its declaration, and run an agent against it in manual mode, watching what drift it detects before letting it act. Progress at that pace beats any big-bang conversion, and it surfaces surprises while they are still cheap. Curiosity also helps: operations teams who want context on how automation and alerting fit together can read a simpler way to understand AIOps and modern IT operations, since the reconciler will eventually become one more well-behaved component in that wider picture. The habit to carry over from mission control is not the technology at all. It is the discipline of declaring the target, letting a reviewed process do the reaching, and trusting a steady cycle of small corrections over occasional heroic ones.