Sooner or later, every delivery team stands at the same junction. One path keeps the pipeline in charge: a build finishes, and the pipeline reaches out and installs the result wherever it needs to go. The other path hands the steering to the cluster: software sitting inside the system watches a repository and helps itself to whatever the record says should run. The second path is GitOps, and the honest comparison between the two is friendlier and more useful than the social-media threads suggest — each side has real costs, and knowing them beats picking a tribe. Let us walk through the comparison the way a colleague would over coffee, axis by axis, with the trade-offs stated plainly rather than scored by fandom.
Where the credentials live: the push-versus-pull split
This is the axis with the sharpest edges. In a push arrangement, the pipeline must hold credentials that open production — it cannot install anything without them. That means your build system, which also runs third-party plugins and untrusted test code, sits inside the security boundary of your most sensitive environment. NIST thought about this carefully in SP 800-204C: the publication explains that pushing exposes cluster credentials to the pipeline and judges push-based models insecure on precisely that ground. The pull arrangement inverts the flow. An agent lives inside the cluster, holds only what it needs to read the repository and write to its own system, and nothing external ever needs a door key. The repository, meanwhile, needs no trust at all — it is just text. When teams describe why they migrated, this axis is usually the reason; everything else on this page is a consequence or a footnote. It also pairs naturally with the broader security work described in how DevSecOps transforms release safety and cuts risk, since both efforts shrink the number of places a secret can leak from.
GitOps and CI: rivals or flatmates?
The comparison everyone gets wrong is the one against continuous integration, because the two are not actually competing. CI takes a commit, builds it, runs the tests, and produces an artefact worth shipping. That work is unchanged under GitOps. What moves is the delivery step: instead of CI taking the artefact and installing it, CI publishes the fact that a new version exists — typically as an image with a digest — and updates the declaration that the agent watches. The pipeline stops being the deliverer and becomes the proposer. Teams that try to run both models at once end up confused about who owns production, so the clean division is worth stating on a wall somewhere: CI decides what is ready; the pull loop decides what is running. Anyone who has maintained a reliable CI/CD pipeline for a delivery team knows the relief of a boundary like that — fewer midnight mysteries, clearer ownership.
GitOps and infrastructure as code
Another frequent muddle: is this just infrastructure as code with better marketing? Not quite, and the distinction is practical. Infrastructure as code is a language — a way to describe servers, networks, and databases as files instead of ticket queues. GitOps is an operating model — a decision about who may change the running world and how changes are enforced. You can write infrastructure as code and still deploy it by hand from a laptop, which plenty of teams do; nothing about the language forces discipline. Equally, a GitOps setup can reconcile application configuration that was never touched by an IaC tool. The two fit together well — the declarations usually are written in IaC or template formats — but one is vocabulary and the other is governance. Adopting the first without the second gets you nicely formatted chaos.
GitOps and release strategy: who owns the canary?
A third boundary deserves chalk. How a new version reaches users — all at once, in canaries, behind feature flags, with automatic rollback on error — is release engineering, and GitOps does not replace it. The reconciler answers “what should run?”; progressive delivery answers “how should it arrive?”. Tools exist for the second question, Flagger and Argo Rollouts among them, and they compose with a pull-based setup rather than competing with it: the record declares the strategy, and the machinery executes it. Teams sometimes expect the migration to deliver canary analysis as a side effect and are disappointed. Name that disappointment early: adopting the pull model organises delivery, while release strategy remains its own craft with its own decisions.
The catch: what the pull model asks of you
Friendliness obliges honesty, so here is the bill that arrives with the pull arrangement. The agent is privileged software — out of the box it tends toward cluster-admin, which is far more than most workloads need — so you will want to narrow it with application projects, impersonated service accounts, or the lockdown flags Flux provides. The repository quietly becomes a credential itself: write access to a path the agent watches amounts to deploy permission, which makes review rules and branch protection part of your security posture, not just etiquette. And the webhook story is less magical than advertised — it does not deliver changes, it merely rings a bell that triggers an earlier pull; Argo CD, for instance, polls on its own about every two minutes with jitter on top, so the webhook saves latency and costs you an endpoint that has no rate limiting of its own. Give it a shared secret. None of these are dealbreakers. All of them are cheaper to know in advance than to discover in an incident, a theme familiar to anyone who has catalogued the adoption mistakes companies most often make.
Where each delivery model genuinely wins
Balance matters in a comparison, so credit where it is due:
- Push delivery shines when speed of first setup matters most, when the fleet is a single cluster, and when the pipeline is already hardened — a weekend project can be shipping by Sunday night.
- Pull delivery shines as surface area grows: more clusters, more tenants, more audit questions, and more engineers who should never have had production credentials in the first place.
- Hybrid arrangements exist and are common — pulling for long-lived environments while a pipeline pushes into disposable preview setups that hold no secrets worth stealing.
The failure pattern is not choosing the “wrong” column; it is drifting between columns without deciding, so that nobody can say which system owns production on a given Tuesday.
So which model should your team pick?
If you have read this far hoping for a verdict, here is the fair version. Push delivery is not ridiculous — it is fast to set up, familiar to every pipeline author alive, and defensible for small, low-risk systems where the pipeline is already locked down tight. But as the number of clusters, environments, and hands grows, its weaknesses compound: more credentials in more places, less visibility, and rollback by rerunning history. The pull model trades a bit of setup for a system where the record is the authority, drift announces itself, and the safest thing an outsider can do to your production is open a pull request. For a structured side-by-side of the trade-offs, including the weighted scoring some teams use, the GitOps comparison notes at xOps School lay the decision out with unusual care. Whatever you pick, pick it deliberately — the worst of both worlds belongs to teams who never chose at all.
