After last month’s piece on deployment discipline, the questions arrived by the fistful — from flight instructors who maintain their school’s booking site, from charter desk staff who tweak the schedule page, from one airline recruiter who wanted to know what all the fuss was about. The questions were good, so they deserve answers in full, given over an imaginary coffee in the pilot lounge. GitOps sits underneath most of them, and it turns out aviators ask exactly the questions the practice is built to answer.
So What Is GitOps, in One Honest Sentence?
You write down how the system should be configured, keep that written description in version control where every change is tracked and approved, and let automated software continuously pull that description and hold the live system to it. That is the whole idea. The thermostat on your wall works the same way: you set a number, the device measures the room and corrects itself without asking you twice. Software teams built the same loop on purpose, with review and history attached, because servers misbehave more expensively than living rooms.
If Our Pipeline Already Applies Changes, Isn’t That GitOps Too?
Usually not, and the gap is worth understanding. The community formalised four principles, and a delivery pipeline that reaches into production and applies changes typically satisfies only half of them:
- The configuration is declared as an end state, not as scripted steps — a careful pipeline often manages this one.
- The configuration lives in a versioned, immutable store — sometimes true in pipeline setups, just as often nothing is pinned.
- An agent inside or beside the running system pulls the configuration — here the pipeline model fails outright, because the pipeline pushes.
- The system is reconciled continuously — which no one-off apply job does, however often it is scheduled.
Two of four is a common score, and it is why so many teams feel they “basically do this already” while missing the part that guards them at 3 a.m.
Is GitOps the Same Thing as Infrastructure as Code?
Close cousins, different jobs. Infrastructure as code is the language — the way you write a database, a network, or a load balancer as a text definition instead of clicking through a console. GitOps is the operating model — the agreement about where that text lives, how changes to it are approved, and what enforces it afterwards. You can write infrastructure as code and never come close to GitOps: plenty of teams keep templates in a shared drive and apply them by hand whenever someone remembers. The grammar without the governance, in other words. Aviation has the same distinction: a checklist (the artefact) versus a culture where the checklist is actually flown (the model). You need the first to attempt the second, but owning the first proves nothing.
Does All of This Require Kubernetes?
No, though Kubernetes is where the practice grew up. The same pull-and-reconcile pattern now reaches cloud resources — databases, queues, DNS entries, whole network topologies — through provisioning tools that an agent can drive, so the declared-and-enforced approach extends well beyond container platforms. Even the repository itself is negotiable: any versioned, append-friendly store qualifies, which is why you will run into setups that keep their recorded state in a container registry or a versioned bucket rather than a traditional code host. Purists grumble; the principles hold either way. What matters is that the record cannot be quietly rewritten and that something untiring enforces it.
How Does the Agent Know When to Act?
Mostly by asking. A reconciliation agent polls the record on a short interval — Argo CD, for instance, checks roughly every two minutes, with a little random jitter so a thousand agents never stampede at once. Webhooks exist, but they only make the agent look sooner; the system never accepts a change from outside, it just gets told there is something new to read. That design has a security footnote worth repeating to anyone who manages such an endpoint: it generally lacks rate limiting, so configure a shared secret and keep it rotated. The rhythm feels familiar once you put it in aviation terms — an agent polling on an interval is a heading bug being re-checked every cycle, not a student staring at the instrument hoping the number changes.
Won’t the Automation Fight Us During an Incident?
It will, if you let it, and this is the question that separates thoughtful adopters from sorry ones. An agent that repairs deviations is wonderful until 02:00, when a responder needs to shut a component down and the agent helpfully restarts it, again and again, while the customer impact grows. Mature setups therefore ship with a documented override: suspend the affected part of the automation, make the emergency change by hand, then bring the agent back and let it settle against an updated record. Rehearse that override before you need it. A helpful enforcer with no off switch is not a safety feature; it is a second emergency happening inside your first one.
Where Should a Small Team Begin?
Small, self-hosted, and boring. The standard opening move is to point the new agent at the folder that defines the agent’s own setup, so from its first minute the enforcer is governed by the same rules it applies to everyone else. Growth comes one small workload after another — never in batches — and the automated removal of anything no longer described stays disabled through the early weeks, earning its activation only after the record and the live system have agreed for a comfortable stretch. Bring secrets into the plan early so credentials never enter history. Anyone who wants the complete formal statement — principles, security reasoning, and the current tooling — will find it collected in a detailed GitOps reference, which is the document to read before arguing terminology with your local platform engineer.
What Does This Have to Do With Flying?
Less than a checklist and more than you would think, and the readers who write in keep proving it. One instructor described migrating her school’s scheduling site after a volunteer’s unrecorded edit wiped the aircraft-booking rules for a weekend — her words were “we needed something that checks itself, because we are all volunteers.” A charter pilot asked whether agents and autopilots differ; the honest answer is that both hold a set value against a reference, but only one of them files its decisions for review. And for readers plotting a route into the technical side of aviation-adjacent work, structured programs such as DevOps training in Bangalore or a grounding in build-and-artefact tooling via Artifactory courses in Mumbai pair naturally with the GitOps layer described above — the first teaches the pipeline, the second teaches what the pipeline produces, and the practice in this article teaches who is allowed to ship it. Even the commercial side connects: when busy professionals choose private charter, they are buying dependability, and dependability is manufactured by exactly the reviewed, self-correcting discipline this page has been describing.
The short version, for the noticeboard: write the intended state, version it, approve changes in company, let an agent pull and enforce — and rehearse the off switch before the night you need it.
Send the next round of questions. The best ones so far have come from people who run aeroplanes for a living, probably because aviators were sold on written procedure, continuous checking, and honest instrumentation long before the software industry invented its own words for them. GitOps is one of those imports that lands well: the vocabulary is new, but the habits are ones this readership has been flying with for decades.
