{"id":904,"date":"2026-10-19T05:10:00","date_gmt":"2026-10-19T05:10:00","guid":{"rendered":"https:\/\/lightsportwest.com\/blog\/?p=904"},"modified":"2026-10-19T05:10:00","modified_gmt":"2026-10-19T05:10:00","slug":"gitops-plain-language-pull","status":"publish","type":"post","link":"https:\/\/lightsportwest.com\/blog\/gitops-plain-language-pull\/","title":{"rendered":"GitOps in Plain Language: How the Pull Model Works"},"content":{"rendered":"

Strip away the vendor slides and GitOps is a short sentence with a long tail of consequences: the configuration a system should run is written down once, kept in a version-controlled record, and an automated agent working inside the system pulls that record and quietly reshapes the running system to match it \u2014 over and over, forever. This piece explains the mechanism in plain language, then does what an evidence-led reader should always do afterwards: examine the claim, weigh the costs, and separate the real thing from the lookalikes.<\/p>\n

GitOps in Plain Language: The Four Moving Parts<\/h2>\n

Every working setup, however fancy the dashboard, consists of the same four components. Understand them and you understand the whole model:<\/p>\n

    \n
  1. The declaration.<\/strong> A plain-text description of the system’s intended end state: which programs run, in what quantity, with which settings. Not a script of steps \u2014 a statement of the destination, like a flight plan rather than a list of control movements.<\/li>\n
  2. The versioned store.<\/strong> The declaration lives somewhere that keeps full history and refuses silent rewrites \u2014 a Git repository is customary, but a versioned bucket or container registry serves equally well. The store is the single authority: if it is not written there, it is not the plan.<\/li>\n
  3. The agent.<\/strong> A small program running inside or alongside the system, whose whole job is to read the store, observe the live system, and compare the two. It holds no secrets from the outside world and needs no inbound access \u2014 it reaches outward to read the record.<\/li>\n
  4. The reconcile loop.<\/strong> The agent acts on every difference it finds. An approved change in the record gets applied to the system; an unapproved change in the system gets reverted or flagged. The loop runs on a timer \u2014 every couple of minutes is typical \u2014 and continuous is the operative word: a poll every three minutes qualifies fully, because the model never promises instant, only unending.<\/li>\n<\/ol>\n

    A refrigerator is the humblest possible mental model. You do not instruct a refrigerator to cool each hour; you set a target, and a modest mechanism measures and corrects around that target all day without your involvement. Replace the target temperature with a declared configuration and the mechanism with a reconciling agent, and you have the entire architecture.<\/p>\n

    Why Pulling Beats Pushing on Safety<\/h2>\n

    The direction of the transfer matters more than any other design choice, and the reasoning is worth following to the end. In the older push pattern, the build system holds credentials that let it reach into production and change things \u2014 which means those credentials exist outside production, in whatever system assembles your software. That system becomes a high-value target, and guidance on securing service-based architectures (NIST SP 800-204C is the standard citation) draws the conclusion bluntly: push-based deployment deserves to be treated as insecure by default, because whoever takes the build system takes production with it.<\/p>\n

    The pull pattern inverts the flow. Production holds its own credentials and never shares them; the only thing the outside world needs to provide is read access to one directory of the record. An attacker who compromises the build system finds nothing but build tools, and the worst they can do is propose a bad change \u2014 which must still pass a human review before the agent will honour it. Evidence for this ordering is not merely theoretical; it follows from the shape of the permissions, the way the direction of a one-way valve follows from its geometry.<\/p>\n

    The Honest Counterweights<\/h2>\n

    An evidence-led reader pays as much attention to the costs as to the wins, and this model has two that deserve plain speech. First, the agent itself wields real power \u2014 by default often more than it needs \u2014 and a misconfigured one becomes the very weakness the model was meant to remove. The established fixes are least-privilege scoping, project boundaries, and impersonated accounts, all of which require someone to actually do them. Second, the record becomes the master key: anyone or anything that can write to the watched path can ship software. Write access therefore gets audited like pilot currency \u2014 named, current, and reviewed \u2014 and that includes non-human writers, because an AI assistant that can push to a monitored path is a deployer in every sense that matters.<\/p>\n

    There are smaller practical notes, too. Webhooks, which many setups add to trigger an earlier pull, do not replace the timer \u2014 they merely wake the agent sooner \u2014 and they generally lack rate limiting, so a shared secret on the endpoint is not optional. And the loop’s patience is a design choice, not a defect: teams used to instant deploys occasionally misread a two-minute settle as slowness, when it is actually the cost of verification happening continuously rather than never.<\/p>\n

    How to Tell GitOps From Its Lookalikes<\/h2>\n

    Because the term sells, it gets borrowed. Three quick tests separate the genuine article from the imitation, and each takes under five minutes to run:<\/p>\n