Hospital IT runs on precision. A misplaced assumption about a drug chart or a ventilator alarm is never a debating point; it is a safety event waiting for a shift change. The same standard should apply to how we discuss GitOps, the operating model in which a system’s desired state is written down as a declaration, kept in a versioned store, and pulled continuously by software agents that reconcile the live platform against it. Few technologies collect mythology as quickly as this one has, and in a clinical environment those myths cost real money and real time. Below are six that keep resurfacing in procurement meetings and architecture reviews, each checked against what the model actually asks for, with the reasoning spelled out rather than asserted. Where a claim needs a source, we lean on the Ops Atlas entry on GitOps kept by xOps School; everything else here is reasoning you can test on your own cluster.
What GitOps actually is, stated precisely
Strip away the marketing and four requirements remain. They trace back to the OpenGitOps principles, and every myth in this article fails against at least one of them:
- Declared end state. The configuration you want is written as a description of the outcome, not as a script of commands.
- Versioned, immutable history. That description lives in a store which preserves every revision and refuses quiet overwrites.
- Agents that pull. Software inside the platform fetches the declared state on its own schedule; nothing outside pushes changes into production.
- Continuous reconciliation. The comparison never stops. A poll every few minutes is enough; convergence is ongoing, never a one-time act.
A build job that finishes by running kubectl apply against the cluster can satisfy, at most, two of the four. That single test quietly retires half the confusion in this field. It also explains why the serious question in any adoption programme is not which tool was chosen, but how quickly a disagreement between declaration and platform gets noticed, and who is obliged to close it.
Myth 1: “GitOps is just YAML parked in a repository”
This is the most common and the most expensive misunderstanding. Storing manifests in version control is a filing exercise. GitOps begins when something acts on the filing: an agent notices that the live system and the declaration disagree, and it moves the system back toward the declaration, repeatedly, without being told each time. A clinical analogy holds here. A written protocol in a patient’s chart is not care; care is the protocol plus the observation chart plus a nurse who responds when the readings wander. Remove the responding agent and you are left with documents. If your team keeps manifests in Git but applies them by hand whenever somebody remembers, you have a document repository with ambitions. The reconciliation loop is not an accessory to the model. It is the model.
Myth 2: “GitOps makes continuous integration obsolete”
Nobody who has read the model carefully claims this. Integration still has to compile code, run tests, scan images, and produce versioned artefacts; that work belongs to CI and stays there. What changes is the deployment half. Under GitOps the pipeline stops at the boundary of production: it renders, publishes, and updates a declaration, and a reconciler inside the platform takes over from that point. The distinction also matters for blame allocation during incidents. When deployment is a pipeline stage, a failed rollout becomes a CI problem, and CI teams inherit responsibilities they cannot observe. With the pull model the parts stay separable: CI answers “is this artefact good?”, while the reconciler answers “does the running system match what was agreed?”. Teams that adopt GitOps without rebuilding their CI setups are not cutting corners; they are doing what the model prescribes. The build server keeps its existing schedule, and production gains a guardian that works nights and weekends without being asked.
Myth 3: “It only speaks Kubernetes”
Argo CD and Flux made Kubernetes the model’s first home, and the principles were drafted with clusters in view, but the pattern has outgrown that address. Crossplane and the tofu-controller reconcile cloud resources — databases, queues, DNS records — through the same declared-state-and-converge loop. There is even a “Gitless” variant: the versioned store need not be Git at all, because an OCI registry or a versioned object bucket can hold the declaration just as well. What the model requires is a store that keeps revisions intact, not a particular product. For hospital platforms running a mix of clusters, managed databases, and older virtual machines, this matters. GitOps describes a discipline that stretches across such an estate as far as reconcilers exist for each piece; the estate does not have to be uniformly Kubernetes to qualify, and treating the model as a Kubernetes feature undersells it.
Myth 4: “The repository doubles as a backup”
This one causes quiet damage because it sounds responsible. A repository holds declarations: the shape of the system, its versions, who agreed to what. It does not hold the contents of databases, the data sitting on persistent volumes, or the records those systems process — deliberately so, because mixing data with configuration creates privacy and access problems a compliance team would have to unwind. Restoring a deleted namespace after a pruning accident requires backups of the data, not the repository. The two artefacts answer different questions. The repository answers “what should exist?”; the backup answers “what did exist, and can we get it back?”. A hospital that discovers mid-incident that its restore plan was a git clone has learned an expensive version of this distinction. Keep declarations in version control, keep data in tested backups, and never let one stand in for the other.
Myth 5: “GitOps is a release strategy”
Canary launches, blue-green switches, and feature flags decide how much of a new version users see, and when. That is release engineering — sometimes labelled ReleaseOps — and it sits above the operating model rather than inside it. GitOps answers a narrower question: what is the agreed state, and is the platform running it? A team can reconcile declarations while shipping everything at once to everyone, or run careful canaries through a pipeline that ends in a declaration update. The practices combine well, but they are not the same practice. Procurement documents that file GitOps under release-management features are usually selling automation that never reconciles anything. Put one question to the vendor: after the declaration changes, which component notices, and how quickly does the live system move? A truthful answer names a reconciler and a polling interval. A dodgy one describes a deploy button.
Myth 6: “The git log is a complete audit trail”
The history of a well-run repository has genuine value: every change, its author, its reviewer, its timestamp. But it records intent, not behaviour. Whether the reconciler actually converged, when drift appeared, what the agent corrected at three in the morning — those facts live in the reconciler’s events and metrics, not in commits. The Argo CD project makes the same admission in its own guidance: a complete record needs the events. An auditor handed only commit history sees a well-behaved system with no incidents, because incidents in this model usually take the form of the platform disagreeing with the declaration between reviews. Export reconciler events, retain sync histories, and treat the commit log as one chapter of the record rather than the whole book. In regulated environments — and hospitals are nothing if not regulated — the difference between the two determines whether an audit closes or returns findings.
Why this discipline suits clinical platforms
Read the corrections above together and a pattern appears: GitOps rewards organisations that already think in protocols, checkpoints, and follow-up rather than heroic one-off interventions. Medicine writes the recovery pathway down, watches the patient against it, and escalates on deviation. The guides this site publishes on adult CABG recovery and cardiac rehabilitation after heart surgery are that same instinct in clinical dress, and continuous follow-up — the logic behind telehealth-supported follow-up care — is the clinical cousin of a reconciliation loop. A platform operated on identical lines is auditable by construction: the agreed state is written, the running system is compared against it on a schedule, and every correction leaves a trace. None of the six myths survives contact with that loop, which is exactly why they are worth retiring before the next architecture review.