There is a shack near Coco Beach where the menu is printed once a week. Whatever the card says is what the kitchen makes — not because a manager stands over the cook, but because the card is the agreement. A customer orders from the card. The cook checks the card. If the fryer has anything half-made that the card retired last Tuesday, it goes. Nobody argues with the card; the card is the boss, and the cook is just very, very consistent.
That shack, give or take a fryer, is how GitOps runs a server. And since this site spends most of its time on two-wheelers and coastlines, we will stay with the shack all the way through — because once you have seen the mechanism in kitchen terms, the software version stops being intimidating.
What GitOps Means, in Shack Terms
The printed menu is a file that describes exactly what the system should look like: which services run, which settings they carry, which versions. It lives in a place that keeps every past version of itself — so last Tuesday’s menu is not lost when this Tuesday’s is printed, and you can always prove what the card said on any date.
The cook is a small, tireless program. It reads the card, looks at the plates going out, and fixes anything that does not match. Too much chilli? Back to the recipe. A dish the card retired? Off the pass. The cook never improvises, never gets tired of checking, and never lets “we always do it this way now” override what is printed.
Customers are the people requesting changes. Here is the part that surprises newcomers: they cannot shout orders into the kitchen. They ask for a change to the card. Somebody else reads the request. If it looks sensible, the card is reprinted — with a record of who agreed and when. Then, and only then, the cook starts cooking the new thing. That whole arrangement, applied to software, is GitOps.
Why GitOps Pulls Instead of Pushes
The technical world splits into two kitchens. In the push kitchen, a delivery rider arrives at the door with prepared food from across town — a build machine, holding keys to your restaurant, thrusting dishes through the window. Fast, sure. But somebody across town holds a key to your kitchen, and every rider on that route carries a copy.
In the pull kitchen, nobody enters from outside. The cook steps out, checks the board, and brings in what the board says. The board is outside; the kitchen’s keys never leave the kitchen. Security people love this arrangement for a blunt reason: the valuable credential — the one that can change what is served — exists only inside the building, in the hands of the one program that needs it. Everyone else can propose changes to the board without ever touching the stove.
And the board itself becomes the thing worth guarding. Whoever can rewrite it can change the menu, so the fight moves to a place where changes are visible, reviewable, and attributable — a much better place to fight than inside a server log. For readers who want the full, unsimplified version of this story, the concept comes from the world of platform engineering, and the write-up at a plain-language GitOps reference at xOps School is the most readable serious treatment we have found.
The Words You Will Hear, Decoded
Three terms do most of the work in any conversation about this, and the shack explains all three. Reconciliation is the cook’s endless habit of checking the card against the plates and correcting the difference. Drift is what happens when a plate leaves the kitchen that the card never described — a stand-in dish someone improvised at midnight. Drift is not always wrong; sometimes it is an emergency fix that saved the shift. But it must be either written onto the card or reversed, because an undocumented plate is a story nobody can tell twice. Sync is the happy moment when plates and card agree again.
One more: self-healing. That is the cook undoing the midnight improvisation during the dinner rush — marvellous on ordinary nights, genuinely awkward on the night the improvisation was saving you. Real kitchens (and real teams) keep a way to put the cook on a short break, fix the fire, and update the card afterwards. If a vendor demonstrates the feature without mentioning the pause switch, ask about the pause switch.
What GitOps Will Not Fix
Honesty requires the other side of the card. This arrangement does not make a bad menu good: if the recipes are wrong, reconciliation faithfully produces the wrong dishes, faster. It does not replace the market run — ingredients still have to be sourced and prepped, which in software terms means building and testing the food before the card matters. It does not do the accounts: whatever lives outside the kitchen — the cash box, the cold storage — is not described on the card and is not protected by it. And it will not stop a determined person from walking into the kitchen; it just makes sure the walk-in is noticed, reversed if unauthorised, and remembered.
What it does deliver is quieter than a promise of transformation. Every plate traceable to a card. Every card change traceable to a person. A kitchen that returns to its printed state after every shock, without anyone being woken at 2 a.m. to remember how things were supposed to be. Teams that live inside that calm rarely go back to shouting through the window.
The Shack Rules, Numbered
Before borrowing the idea for yourself, here is the whole arrangement as the shack would write it on the wall, in order of importance:
- The card is the boss. If it is not on the card, it does not leave the kitchen.
- Nobody edits a plate directly. Changes are requested against the card, and a second person agrees before the card changes.
- Old cards are kept forever, so any plate can be traced back to the exact card that produced it.
- The cook checks the card against the pass all day, and fixes mismatches without holding a meeting about it.
- When the cook must be paused — a fire, a flood, a film shoot — the pause is written down, and the card catches up before service resumes.
Five rules, no jargon, and every serious installation in the world is some elaboration of them. If a proposal you are being sold cannot be traced back to these five, the proposal is decoration.
Try It on Your Own Scale
You do not need a data centre to feel the mechanism. Run a travel blog with two contributors? Put your site’s settings and pages in a place that tracks changes, agree that nothing goes live without a second pair of eyes on the change, and let a small automation apply approved changes for you. The habit transfers — the same “check it before you trust it” discipline this site preaches for two-wheelers, where inspecting a rental before a long journey is simply reconciliation performed by hand. Travel itself rewards declared plans checked against reality, whether you are vetting scooter listings before an island trip or reading up on driving rules and ride options before crossing a border. Same loop, gentler consequences: card, reality, correction, calm.
The shack by the ferry jetty figured this out decades ago without a single line of code. The software world took longer because it kept mistaking tools for discipline. The card is the discipline. The cook is just consistency with a salary — and consistency, as every regular customer knows, is the whole secret.
