Families who plan treatment abroad already know how much depends on a written plan: the procedure agreed in advance, the credentials checked, the follow-up scheduled before anyone boards a flight. GitOps applies that same instinct to computer systems, and this primer explains it in the same practical spirit this site brings to care abroad — plain words, short sections, no term left undefined. Whether you are a clinician curious about the software running your hospital, a manager asked to approve a budget line, or simply a beginner who keeps meeting the word and wants it demystified, the next ten minutes will give you the vocabulary, the core idea, a few honest numbers, and the questions that separate substance from sales pitch.
What GitOps is, in plain words
The whole model fits in four short statements. The team describes the condition it wants its systems to be in, the way a surgical plan states the intended outcome before the first incision. That description is kept in a place where nothing is ever overwritten and every change stays on the record — think consent forms, versioned and filed, never replaced quietly. The platform’s own software goes and collects the description on a schedule, instead of outside tools pushing changes in. And finally, the running system is compared against the description over and over, corrected when it wanders and flagged when correction is not wanted — waiting a few minutes between sweeps is normal and still counts as continuous. That last part, the repeated comparing and correcting, is what makes this an operating model rather than a filing system. For the full technical picture behind this summary, the full GitOps guide at xOps School is the reference the industry itself points to.
The treatment-journey version of the idea
Consider how a well-run surgical journey behaves. The plan is written before anything happens: procedure, implants, medication, follow-up checkpoints. The written plan does not change because someone had a busy morning; if the plan must change, the change is recorded as a new entry with a name and a reason attached. Progress is checked against the plan at every follow-up — wound healing on schedule, medication as prescribed — and a deviation is either corrected or consciously accepted and noted. Nobody confuses the plan with the patient records: the plan says what should happen, the records hold what did happen, and both are kept carefully but separately. GitOps gives servers exactly this arrangement. The declared configuration is the plan; the agents are the follow-up schedule, always checking; a substitution made without going through the review process is a deviation, whether the deviator meant well or not; and the store describing the system is never treated as a substitute for the systems that hold actual data.
A mini-glossary before we go further
These eight terms cover most beginner conversations about the topic:
- Desired state — the written description of how everything should be configured.
- The store — where that description lives, keeping every version in order; Git is the usual choice, though not the only one.
- Reconciler (or agent) — the software inside the platform that reads the description and keeps reality matched to it.
- Sync — one round of the reconciler making the running system match the description.
- Drift — any difference that appears between the description and reality, usually because someone changed something directly.
- Pull model — the arrangement where the platform fetches its own instructions, rather than outside tools delivering them.
- Prune — the reconciler removing things that the description no longer mentions; powerful, and worth handling with respect.
- Break-glass access — a drilled escape hatch for emergencies that bypasses the automation on purpose, with the change recorded and backfilled afterwards.
- Manifest — one file within the description, usually covering one piece of the system.
- Overlay — a small set of changes layered over shared files so, say, staging and production can differ in a few lines instead of by full copies.
- Promotion — moving a change that proved itself in a test environment forward into production by referring to the exact same tested version, never a fresh look-alike.
Watch how the terms cooperate in an ordinary working day. A developer edits a manifest and opens a change for review; a colleague reads the rendered result and approves; the merge lands in the store; the reconciler’s next scheduled pull collects it, syncs the platform, and reports the outcome. Later that week, someone edits the live platform directly, skipping all of it — and the next sweep reports drift, because the store no longer describes what is actually running. No single piece is complicated. The discipline is that the pieces run in this order every time, which is more than most manual processes can claim.
What GitOps is not, for beginners
Three clarifications prevent most early confusion. It is not a backup: the store holds the description of the system, never the data flowing through it — treatment plans and treatment records are kept apart for the same reason. It is not a release strategy: choosing whether a change goes to one patient-facing page or all of them, gradually or at once, is a separate decision that layers on top rather than living inside. And it is not a monitoring dashboard with ambition: watching a system and enforcing agreement between it and a written standard are different acts, and only the second one changes anything. Keep these boundaries in mind and you will recognise when a vendor slides the word into a feature list where it does not belong.
Why the pull model matters to privacy-minded readers
The direction of travel decides who holds the keys. In the older push arrangement, an outside tool carries working credentials and reaches into the platform to make changes, which means the credentials to your most sensitive systems sit in whatever tool, script, or contractor laptop does the pushing. In the pull arrangement the platform collects its own instructions, the keys never leave home, and the outside world needs nothing more than a place to publish the plan. Formal guidance agrees: the United States standards publication NIST SP 800-204C judges push-based delivery effectively insecure for exactly this reason. For organisations that handle medical records — where the consequences of a leaked credential are measured in privacy, not just downtime — this single architectural choice carries most of the argument.
Numbers a beginner can actually trust
Honest numbers beat polished promises, so here is one team’s published week of real measurements, failures included. About one application attempt in five failed to apply and needed a correction — the machinery is useful, not magical. Four of the six drift events the team caught were reverted properly through the review process, which tells you the loop catches real problems rather than imaginary ones. And four out of five changes made directly on the running platform had no ticket behind them, which is the number that should make any process-minded reader wince: side doors get used unless they are closed on purpose. Beginners should take two lessons from figures like these. Expect failures and budget for them, because a failure caught by an agent is a far cheaper event than one caught by a patient. And treat side-door usage as the metric that predicts everything else — while people can bypass the plan quietly, they eventually will.
Questions worth asking, borrowed from checking hospitals
Readers of this site are practised at vetting institutions they cannot visit — the same skill behind checking a hospital’s accreditation before travelling. Apply it to any team selling you GitOps tooling or services. Ask where the declared description lives and whether you can read its history yourself. Ask what percentage of production changes travel through the reviewed route, and what happens to the rest. Ask how you would find out, and how fast, if reality wandered from the written plan. Ask what their restore story is for data, and whether anyone has tested it this quarter. The team with confident, specific answers is the one to shortlist — the instinct is identical to the essential questions to resolve before surgery abroad, and to the reasoning in how careful comparison protects a treatment journey: verify the claim, in writing, before you commit. Systems, like surgeries, go best when the plan is written, the checks are scheduled, and nothing important is left to memory.