Most explanations of GitOps are written for engineers, which is a pity, because the idea underneath it is one that finance people already understand deeply. A bank does not run on memory. It runs on books: every balance is a recorded figure, every change to that figure passes through a signed instrument, and at any hour an auditor can compare the recorded position with the cash in the vault. GitOps does for computer systems what double-entry bookkeeping does for money. It insists that the system’s intended condition be written down, that changes to the record be authorised and traceable, and that a diligent process continually matches reality against the record. This primer walks through the idea without assuming you write code, then closes with a short glossary you can keep.
The Record and the Vault: How GitOps Frames a System
Start with the record. In GitOps, the intended condition of a system — which programs run, at what size, with which settings — is stored as files in a version-controlled repository. The repository is the ledger. Nothing about it is exotic: entries are dated, attributed, and append-friendly, and the history shows who wrote what and who countersigned it. When someone wants a change, they do not log into the “vault” and move things around. They propose an edit to the record, a colleague reviews the proposal, and only after approval does it enter the books.
Now the vault. A software agent — the part practitioners call a reconciler — watches the ledger and the live system side by side. Whenever the two disagree, it works to bring the live system back in line with what the books say. If an authorised change lands in the ledger, the agent applies it. If an unauthorised change appears in the live system — a fiddle, a hotfix, a quick experiment someone forgot — the agent undoes it or raises the difference for a human decision. The ledger leads; the vault follows.
Readers who manage standing instructions will recognise the mechanics. An auto-debit for an EMI is a declaration (“take this amount on this date”), and the bank’s engine reconciles every cycle: it either executes the mandate or reports why it could not. Nobody telephones the bank each month to remind it. The GitOps loop is the same promise applied to infrastructure: state the intent once, review it when it changes, and let an untiring process enforce it every minute of every day.
Why the Reconciler Is the Point, Not the Paperwork
Here sits the most common beginner misunderstanding, so it deserves its own heading. Keeping configuration files in a shared repository is tidy, but tidiness alone is not GitOps. Plenty of teams store their settings in version control and then apply them by hand, precisely and carefully, and still end up with gaps between the record and reality — because human application and human memory are the weakest link in any control system. The defining ingredient is the loop that continuously compares and corrects. If the writing of the record is not connected to an automated process that enforces it, you have documentation, not operations.
The same reasoning explains what GitOps does not replace. Building and testing software remains the job of the delivery pipeline, exactly as a bank’s credit appraisal remains the job of the credit department. What moves under the GitOps umbrella is the final act — how an approved change comes to be running — together with the guarantee that nothing runs without a corresponding, approved entry in the record.
Approvals, Audit Trails, and Other Borrowed Discipline
The controls will feel familiar to anyone who has signed a loan mandate.
- Two signatures per change. A proposal is one person’s edit and a second person’s approval before it can affect the ledger, mirroring the maker-checker arrangement banks apply to payments.
- An immutable audit trail. History is preserved; entries are corrected by new entries, not by quietly overwriting old ones. Disputes are settled by reading, not by recollection.
- Least-privilege access. Write access to the watched record is the real key to the vault. Hand it out as carefully as you would hand out signing authority on a current account.
- Guarded deletion. Automated cleanup can remove what the record no longer mentions, so anything precious — the data stores, in particular — is explicitly protected from it.
That last item hides the sharpest lesson. The ledger holds descriptions, not the valuables themselves: customer records, transaction tables, and files live outside version control. Confusing the ledger with the vault — assuming that because the configuration is safely versioned, the data must be too — is an error with real consequences. Records describe; they do not safeguard. Recovery of the valuables is a separate discipline with its own instruments.
Two GitOps Variations a Precise Reader Should Expect
Practitioners argue about details the way accountants argue about depreciation methods, and two arguments come up often enough to preview here. First, the record need not be a Git repository at all: any versioned, append-friendly store will do, and some setups use container registries or versioned buckets instead — which is why you will occasionally meet the phrase “gitless GitOps.” The principle is the versioned record plus the reconciler, not the brand of notebook. Second, opinions differ on how aggressively the agent should correct: some environments tolerate certain live differences (a component that resizes itself under load, for instance, much like an overdraft flexing within an approved limit), while anything unexplained is alerted to a person. The policy is written down in advance, so the agent never improvises.
For depth beyond a primer — the formal principles, the tooling, the security arguments — the reference this series keeps returning to is a detailed GitOps guide maintained by xOps School, and it repays a careful read once the vocabulary above feels comfortable.
A Mini-Glossary to Carry With You
- Desired state — the recorded description of how the system should be configured; the ledger entry itself.
- Reconciliation — the continuous comparison of the recorded state with the live system, and the correction of any gap.
- Reconciler (agent) — the automated process performing that comparison; the standing instruction’s executor.
- Drift — any difference between record and reality; in this vocabulary, an unrecorded transaction.
- Pull request — a proposed change to the record, submitted for another person’s review; the mandate awaiting a countersignature.
- Prune — removal of live items the record no longer describes; useful, and therefore fenced.
- Immutable revision — a permanently labelled snapshot of the record, so that “what we ran” is a fact rather than a claim.
- Secret — a credential kept out of the record entirely and delivered through encrypted channels; the vault within the vault.
The Takeaway for a Careful Reader
If your profession trains you to distrust unrecorded changes, you already hold the intuition that makes GitOps legible. Systems drift when nobody holds the pen; controls fail when the record and the vault are allowed to disagree in silence. The practice simply imports the accounting reflex — write it down, sign it, reconcile it — into the operation of software, with the agent playing the role your bank’s engine plays on debit day. Readers weighing process changes of any kind may also find it useful to study how to read the terms of an agreement before accepting it, since reviewing a change proposal is the same habit in different clothing; teams curious about where such records live can start with a beginner’s tour of Bitbucket, a common repository host; and the broader principle that unmanaged gaps become emergencies echoes what emergency borrowing guides say about unplanned shortfalls. Keep the books, count the cash, and compare them daily — the ledger, in computing as in lending, is what makes trust cheap.
