If you have nodded along in meetings where someone said “GitOps” and hoped nobody would ask you to define it, this page is for you. We collect the questions that come up most often, and answer them the way we would explain anything else on this site: plainly, warmly, and without pretending every reader is a platform engineer. By the end you will know what GitOps is, why the pull-versus-push argument keeps flaring up, what it costs to run, and whether it belongs anywhere near your team. And if you want to go past the friendly version, we will point you to the detailed material as well.
So what is GitOps, exactly?
At its simplest, GitOps means you describe how your systems should look — in files, kept in a store that remembers every version and lets nobody quietly overwrite history — and then software agents running inside your platform fetch that description and keep the live system matched to it. Nobody logs into production to make a change. Changes are proposed, reviewed, and merged like any other document edit, and the machines handle the rest. If you want the source material behind these answers, the one place we kept returning to is a detailed GitOps reference maintained by xOps School; it goes several floors below the summary we give here.
Does the name mean I have to run Kubernetes?
No, though we understand why the impression exists. The best-known tools, Argo CD and Flux, grew up managing Kubernetes clusters, so the two ideas arrived bundled together. But the pattern itself is older than either tool and wider than one platform. Crossplane and the tofu-controller use the same describe-and-reconcile loop for cloud resources such as databases and DNS entries. Even the store does not have to be Git: some teams publish their declarations to an OCI artefact store, or to a bucket in object storage that keeps every revision — setups people half-jokingly call Gitless GitOps. What the approach genuinely requires is a versioned, tamper-resistant store, an agent that pulls, and a loop that keeps comparing plan against reality.
Why does everyone argue about pulling versus pushing?
Because the difference is really about who holds the keys. In a push setup, your build pipeline carries production credentials and reaches into the platform to apply changes — which means every pipeline misconfiguration is a potential door into production, and the American standard publication NIST SP 800-204C is blunt that push-based models end up insecure on that count. In a pull setup, the credentials stay inside the cluster, the agent merely needs to read the source, and the pipeline never touches production at all. One nuance confuses newcomers: a webhook does not deliver your changes. It is a doorbell. It simply asks the agent to pull sooner than its next scheduled look would arrive — Argo CD’s habit, for example, is a check roughly every two minutes, with a dash of deliberate randomness. And because webhook endpoints generally have no rate limiting, protect them with a shared secret.
Is GitOps trying to replace our CI pipeline?
Not even slightly, and any vendor implying otherwise is selling you something. Your pipeline still builds the code, runs the tests, scans the images, and produces artefacts — all of that remains integration work and stays exactly where it is. What changes hands is the final leg. Instead of the pipeline deploying into production, it publishes the new declaration, and the in-cluster agent takes it from there. Teams sometimes find this division clarifying during arguments, too: if a build is red, that is a CI question; if production has wandered away from the agreed state, that is a reconciliation question. Two different tools, two different owners, far fewer 3 a.m. debates about whose fault it is.
Can the repository double as our backup?
We wish it were that tidy, but no. The repository holds the floor plan of the building — which services should exist, at which versions, with which settings — not the furniture. Database contents, the data sitting on persistent volumes, and anything your patients or customers actually created are deliberately kept out of that store, for privacy and access-control reasons as much as practical ones. When something goes wrong and you need last Tuesday back, the repository tells you what the system should have looked like, and your tested backups give you the data to put inside it. Both matter. Neither substitutes for the other, and a restore plan that consists of cloning a repo is not a restore plan.
What does running GitOps actually cost?
Three kinds of cost, honestly counted. First, compute: the reconcilers are always working. Argo CD’s rendering component forks Helm and Kustomize for every render, which means you will cap its parallelism and possibly shard controllers as the estate grows, and a genuinely high-availability setup wants three or more nodes. Flux’s cost scales with the number of watched objects multiplied by how often you check them — one production pattern checks sources every minute but corrects drift only hourly, precisely to keep the bill flat. Second, the people cost: every change now passes through a review, and reviews take human minutes. Most teams decide that is the cheapest insurance they have ever bought, but budget for it. Third, learning time, which is front-loaded and smaller than most migrations, since the tools sit beside your existing platform rather than replacing it.
How does a change reach production, step by step?
The journey is short enough to memorise:
- Someone opens a pull request with the change and a colleague reviews it.
- The merge lands, and the agent pulls the updated description on its next cycle.
- It compares what it found with what is running and decides: apply, prune, or roll back.
- It reports the outcome as a status the whole team can see.
Four steps, no logins, and a written trail of who wanted what and who agreed. When something misbehaves, you are not archaeology-ing through shell history; you are reading a small, ordered record. That report-and-reconcile rhythm is also why incidents in this model tend to be small: the agent is constantly tugging the platform back toward the reviewed state, so unreviewed changes have a short shelf life.
What mistakes trip teams up in the first months?
Three, mostly. The first is chasing moving targets: pointing your declarations at a floating tag such as latest, leaving charts unpinned, or tracking the head of a branch for remote bases. Each of those quietly breaks the promise that the same description always produces the same system — pin everything to something that cannot change underneath you. The second is switching on destructive pruning before the team trusts the match between files and reality; the agent is only as faithful as the declaration it was given, and an over-eager prune can delete things you meant to keep. Guard the long-lived things first — namespaces, persistent volumes, the resource definitions themselves. The third mistake is treating the tool as the outcome. Buying Argo CD or Flux changes nothing by itself; the operating habit of reviewing changes before they reach production is the actual product, and the software simply enforces it kindly.
Where should a curious team begin?
Small, staging-first, and with the pruning safety off. Stand up the agent on a non-production cluster and let it manage its own configuration, which teaches you the mechanics with the stakes near zero. Then move one namespace at a time, keeping destructive pruning disabled until the team trusts the match between declarations and reality. Expect the whole shift to take a few months rather than a few weekends, and expect the surprised reactions to be pleasant ones — the first time someone fixes production by merging a file from a laptop on a train is usually the moment the team stops asking whether this is worth it.
One last thought, from the people who ask questions for a living
Much of what makes GitOps work — asking careful questions before acting, writing the plan down, checking the result afterwards — will feel familiar to readers of this site. It is the same instinct behind how good hospitals build personalised treatment plans and behind the questions worth asking after a diagnosis: understand the current state, agree the target, review every deviation. If the wider field interests you, our plain-language tour of XOps and its related operations disciplines shows where GitOps fits among its siblings. Ask good questions of any tooling vendor, of your own pipelines, and of us — preferably in that order.