At a client workshop last year, an operations lead told the room, with real pride, that his team “already did GitOps — everything is in Git.” Ninety minutes later he had quietly withdrawn the claim. Nothing about his setup was broken, exactly. His team saved configuration files to a repository, which is what he had been told GitOps meant. But no software watched those files, nothing corrected the servers when reality wandered, and the whole arrangement amounted to a filing cabinet with good intentions. He had learned the label without the mechanism.
That workshop is why this list exists. GitOps attracts more confident mislabelling than almost any practice in the delivery world, partly because the name sounds self-explanatory and partly because vendors borrow the word freely. Six myths do most of the damage. Each is stated below the way you will hear it in meetings, followed by where it comes from and what is actually true.
Myth One: Files in a Repository Equal GitOps
The most common belief, and the one my workshop friend held. Storing declarations in version control is one ingredient, not the meal. What makes the practice real is reconciliation: an automated agent that pulls the recorded intent, measures the live system against it, and keeps pulling them together. Delete the reconciliation and you have storage with extra steps. The tell is simple — ask what happens after someone edits a server by hand. If the answer is “it stays edited until somebody remembers”, there is no GitOps in the building.
Myth Two: Adopting GitOps Means Dismantling CI
This one frightens teams into deferring adoption. The truth is narrower than the rumour: only the deployment step moves. Builds, test suites, linting, security scans — all of it stays exactly where it is. What changes is the last mile: instead of the pipeline storming into production with credentials in hand, it commits its output to the repository and lets the in-cluster agent take over from there. Teams often report their pipelines get simpler, because a tool that only builds and tests needs far less permission than one that also holds production keys.
Myth Three: It Only Works on Kubernetes
Kubernetes is where the practice grew up, so the assumption is forgivable. But the reconciler pattern does not care what the platform is. Crossplane, which reached graduated status in the CNCF in late 2025, uses the same declared-and-reconciled approach to provision cloud infrastructure — databases, queues, networks, not just containers. Tofu-controller brings reconciliation to Terraform-style workflows. A team running plain virtual machines or a managed database can still adopt the model: the store holds the declaration, the agent holds the authority, and the platform becomes a detail.
Myth Four: The Repository Is a Complete Audit Log
Auditors love this myth because it is nearly true, and nearly true is the most dangerous variety. Version history records what people intended and approved — a genuinely strong story. What it never records is what the system did about it: when the agent reconciled, which drift it corrected at three in the morning, which errors it retried into silence. Reconstructing a real incident takes both sources, the commits and the reconciler events, a point made plainly in Argo CD’s own documentation. The practical fix is retention: keep agent events exportable and reviewed, and stop promising compliance teams a completeness the repository cannot deliver. For a fuller picture of what the model does and does not claim, the Ops Atlas page on GitOps is the most grounded single write-up we have found.
Myth Five: Self-Healing Makes Incidents Trivial
Sales decks imply that reconciliation is a superhero: anything breaks, the agent repairs it. Ask the engineers who have stood in a live incident and you will hear the other half. Mid-outage, a responder may need to scale a service down, pin an older version, or shut a feature off immediately — and a diligent agent will reverse each of those decisions within minutes, quietly fighting the human who is trying to stabilise the system. Mature teams therefore keep a rehearsed escape hatch: suspend the reconciliation, fix the fire, then encode the stable state back into the repository so the agent resumes agreement rather than resuming warfare. The mechanism is a feature. Unexamined, it is a second emergency.
Myth Six: AI Writing Tools Can Push Freely to the Repo
The newest myth is the most relevant to this blog’s readers. Teams now let AI assistants generate configuration and commit it directly to watched paths, reasoning that a machine is faster than a pull request. Reasoning, in fact, is the missing step. Any writer — human or model — that can merge into a watched path holds deploy rights, because the repository is the deployment authority. An automated assistant belongs inside the same fence as a junior freelancer: it proposes changes into a review queue, its output is diffed and read before merge, and its access is scoped to the paths it genuinely works on. We treat this seriously in our own field; the guide on structuring guest posts with AI makes the same argument for editorial review of machine drafts before anything ships.
Where the Myths Come From
Notice the pattern across all six. Each one takes a true fragment — files in Git, automation, strong audit trails, self-correction — and inflates it into the whole practice. Fragment-inflation is how technical fashion spreads through agency blogs, and it is curable the same way every time: find the mechanism, not the label. Templates help with structure but cannot supply the mechanism, as our guide to standardised guest post templates argues for writing; the skeleton is not the story. And when a vendor claims the model will transform your results, ask for the mechanism behind the promise — survey data showing enthusiastic adopters doing well is correlation, not proof, a caveat even sympathetic researchers repeat.
The Short Version, for Your Next Standup
Condensed to card size, here is what survives after the myths are cleared away:
- Saved files are not GitOps; a pulling, correcting agent is what makes the name true.
- Keep your builds and tests. Only the delivery step changes hands.
- Kubernetes is a common home for the practice, never a requirement for it.
- Commits tell auditors intent; reconciler events tell them what actually happened.
- Automatic correction needs a rehearsed pause button for the night something is genuinely on fire.
- A bot that can merge into a watched path is a deployer, with a deployer’s obligations.
A Two-Question Test You Can Run Today
Strip away the vocabulary and audit any setup — yours or a vendor’s — with two questions. First: after a change merges, what software, if any, pulls that change into the live system without a human ferrying it? Second: if somebody edits production by hand tonight, what notices, and how fast? Confident, specific answers to both mean you are looking at the real practice. Hand-waving on either one means you are looking at a filing cabinet with good intentions — and now you know enough to say so kindly, in a meeting, with the checklist to back it up. For teams selling credibility through content, the same discipline of claim-then-evidence runs through building brand authority with guest posting: say what is true, show the mechanism, and let the label take care of itself.