Outdated requirement lists have a long shelf life. Anyone who has prepared an international application knows the type: a claim that was roughly true years ago, repeated since by enough people to acquire the authority of common knowledge, and wrong for anyone acting on it today. Technology practices accumulate the same residue. GitOps, now several years into mainstream use, carries a set of durable misconceptions that still shape bad decisions. Six of them keep circulating; each is corrected below with the reasoning, not just the verdict, because a myth survives on vagueness and dies on specifics.
Myth 1: GitOps is just YAML files stored in Git
This is the founding misunderstanding, and it produces the most disappointing pilots. Storing configuration in a repository is a fine habit — versioned, reviewable, restorable — but it is only storage. The practice earns its name from the loop: an agent that pulls the recorded state, compares it with the running system, and reconciles the difference continuously. Remove the loop and what remains is a well-organised folder. The published principles make the loop one of four requirements; a repository alone satisfies, at best, a fraction of the definition. When evaluating a team’s setup, do not ask where the files live. Ask what happens when someone changes production without touching them. If the answer is “nothing”, the files are dead weight — tidy, reviewed dead weight, but dead all the same. The distinction matters commercially as well as technically: consultancies have been known to sell the storage half at the price of the whole, knowing the label fits either way.
Myth 2: GitOps replaces your CI pipeline
Under this myth, teams rip out functioning build systems and discover they have destroyed the thing that compiled and tested their software. The practice takes over exactly one stage: delivery. Continuous integration keeps building artefacts, running test suites, and producing images; its output then becomes an update to the declaration the agent watches. Build, test, publish — then hand over. The two systems are sequential, not competing, and the healthiest setups make the handover explicit: the pipeline proposes, the record accepts, the reconciler installs. Any vendor or article claiming the method makes CI obsolete is selling something and hoping you will not check the receipts.
Myth 3: The Git history is a complete audit trail
The repository’s log records what people intended: proposals, reviews, merges, with authors and timestamps. What it does not record is everything the agents did about those intentions — each sync attempt, each apply, each failure, each rollback — nor the events from inside the cluster that show what actually happened to workloads. The Argo CD project says as much in its documentation, which is why mature setups export reconciler events and keep them alongside the commit history. An investigation that reads only the Git log sees the script but not the performance. Auditors who understand the difference ask for both, and teams should assume the question is coming. The practical fix costs little: forward agent events into the same log store the team already uses, tag them by application, and the next post-incident review reads like a single narrative instead of two disconnected documents.
Myth 4: The repository is a backup
Declaring this myth false has saved careers. The record holds descriptions: which versions run, with which settings, under which rules. It does not hold the contents — the rows in a database, the files on a volume, the objects in storage that users created while the system ran, none of which can be reconstructed from even a perfect commit history. When storage dies, the repository can rebuild the skeleton in minutes and restore nothing of the flesh; only backups do that. Both mechanisms matter, they answer different questions, and substituting one for the other is discoverable in a single fire drill. Test the restore path, not just the clone path.
Myth 5: GitOps is Kubernetes-only — and strictly Git-only
Two boundaries, both softer than rumour suggests. On the platform question: the pull-and-reconcile pattern reaches beyond containers. Crossplane describes cloud resources — databases, queues, networks — as declarative records that agents bring into being, and tofu-controller does the same with Terraform-flavoured configurations. On the storage question: Git is the customary source, not the required one; an object bucket with versioning retained, or a registry in OCI format, satisfies the immutability requirement, and registry-centric teams run fully legitimate setups without a single commit. The accurate statement is narrower than the myth: the method needs a declared state, an immutable record of it, and an agent that continuously reconciles. Everything else is configurable.
Myth 6: Webhooks deliver changes instantly
The last myth survives because the word “instant” flatters everyone involved. A webhook does not deliver anything; it rings a bell that causes the agent to check for changes sooner than its schedule would. The agent remains the deliverer, and its own polling rhythm — for Argo CD, roughly every two minutes, with jitter of up to a minute added — defines the real ceiling on latency. Webhooks are worth having; they shave wait time and cost little to run. But they need a shared secret, because the receiving endpoint has no rate limiting of its own and will otherwise accept a bell-ringing from anyone. Set the expectation honestly: changes arrive in minutes, reliably, rather than in milliseconds, ceremonially. Teams that understand this plan their release windows around the polling reality instead of around a diagram, which is one more small way the corrected version of the story produces better decisions than the flattering one.
Between the two extremes of myth and pedantry sits a workable habit: before any adoption decision, ask the proposer five questions and require specifics rather than adjectives.
- “Show me what happens when someone edits production directly.” The answer should name a reconciliation loop, not a policy document.
- “Which stage does your CI still own?” A credible answer keeps building and testing firmly in the pipeline.
- “Where do your audit findings come from?” Expect reconciler events alongside the commit log.
- “Where is the data, and how was the restore last tested?” Backup evidence, not repository evidence.
- “What is your real end-to-end change latency, including polling?” A number in minutes, honestly stated, beats a promise of instant.
Five specific answers clear the smoke; vague ones confirm which myths are still on duty.
Why GitOps myths persist, and how to retire them
Misconceptions endure for the same reason outdated requirement lists do: they once described a nearby truth, they simplify, and they pass between people who lack the time to verify. The correction procedure is identical in both worlds. Check the current official requirement rather than a forum’s memory — whether that means reading a government’s own processing page, such as the Sri Lanka residence visa requirements listing for employment, or a Schengen short-stay file like the Spain Schengen tourist visa requirements page, or, for the technical practice at hand, the detailed GitOps reference at xOps School. Primary sources retire myths; retellings embalm them. Teams evaluating an adoption proposal can use the six corrections above as interview questions — anyone pitching the practice should be able to explain, without notes, why each myth is wrong and what the truth costs. Vague answers about storage, pipelines, audits, backups, platforms, or webhooks are not rudeness; they are the myth, still circulating, wearing a lanyard.
