🔁 GitOps for Infrastructure: How Git Becomes Your Control Plane

For most of my career, deploying infrastructure meant a human running an apply from a laptop or a CI job, hoping the state matched reality, and finding out later when it didn’t. GitOps flips that model. Instead of pushing changes out, a controller continuously pulls the desired state in from Git and makes reality match — over and over, forever.

It’s a genuinely different mental model, and once it clicks, a whole class of problems — drift, “who ran that,” failed half-applies — mostly disappears. Here’s how GitOps works for infrastructure and where AI fits.

The four principles

GitOps isn’t a tool, it’s a set of properties. Strip away the marketing and it’s these:

1. Declarative. The entire desired state of the system is described declaratively — what you want, not the steps to get there.

2. Versioned and immutable. That desired state lives in Git, so it’s versioned, auditable, and revertible. Git history is your change log.

3. Pulled automatically. Approved changes are pulled and applied by an automated agent, not pushed by a human with credentials.

4. Continuously reconciled. An agent constantly compares desired state (Git) to actual state and corrects any divergence.

That fourth one is the quiet superpower. It means config drift gets corrected automatically, often within minutes, instead of festering until your next deploy.

Push vs. pull, and why pull wins

Traditional CI/CD pushes: a pipeline holds production credentials and runs apply against your infrastructure. GitOps pulls: a controller running inside the target environment watches Git and applies changes itself.

The pull model has real advantages:

• No external credentials. Your CI never needs prod write access — the in-cluster controller does the applying. Smaller blast radius if CI is compromised.
• Continuous correction. A push happens once; a pull controller keeps reconciling, so drift can’t accumulate.
• Self-healing. Delete a managed resource by hand and the controller recreates it from Git. Reality can’t stay diverged.

Argo CD and Flux are the two dominant pull-based controllers in the Kubernetes world; the same pattern extends to broader infrastructure via tools that reconcile cloud resources from Git.

A minimal GitOps setup

The shape is always: a Git repo of desired state, and a controller pointed at it. With Argo CD, you declare an Application that maps a repo path to a target:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: platform-infra
spec:
  source:
    repoURL: https://github.com/acme/infra
    path: clusters/prod
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true      # delete resources removed from Git
      selfHeal: true   # revert manual drift

selfHeal: true is what enforces “Git is truth” — change something by hand and it gets reverted. prune: true means deleting from Git deletes from the cluster. Both are powerful and both deserve respect, because Git is now genuinely in control.

The workflow changes how you deploy

In GitOps, you don’t deploy by running a command. You deploy by merging a pull request.

1. Open a PR changing the declared state.
2. CI runs the cheap gates — lint, policy-as-code, tests — on the proposed state.
3. A human reviews and merges.
4. The controller notices the new commit and reconciles reality to match.
5. The controller reports sync status back, so you can see when prod actually matches Git.

The merge is the deploy. That’s a clean audit trail (every change is a reviewed commit) and a clean rollback (git revert and the controller un-applies it).

Where AI helps in GitOps

AI fits this model well because GitOps is all about reading and reasoning over declarative state — exactly what models are good at.

Review the diff before merge. The PR is the deploy, so the PR review is the gate. Ask:

“This PR changes our GitOps desired state. Summarize what will change in the cluster, flag anything destructive (especially with prune enabled), and note any resource that would be deleted.”

With prune: true, an accidentally-removed manifest deletes the resource. AI catching “this PR removes the database statefulset” before merge is worth a lot. I keep GitOps-review prompts for this.

Explain sync failures. Paste the controller’s sync error and the manifest; ask for the cause. Reconciliation errors are often opaque, and AI is good at decoding them.

Draft manifests from a description, which you then review and commit — the model writes the YAML, Git and the reviewer keep it honest.

What AI doesn’t do is approve the merge or touch the controller. The human review on the PR is the accountability gate; the controller is the deterministic enforcer. AI makes the review better-informed.

Pitfalls to plan for

A few things bite teams new to GitOps:

• Prune is sharp. A misconfigured path or a deleted file can prune real resources. Protect stateful resources explicitly and review prunes carefully.
• Secrets still need handling. GitOps wants everything in Git, but plaintext secrets must never go there — use sealed-secrets, SOPS, or an external store. See managing secrets in IaC.
• Bootstrap is chicken-and-egg. Something has to install the controller before the controller can manage things. Keep a small, documented bootstrap path.
• Repo structure matters. Decide early how repos map to environments and clusters; refactoring it later is painful.

Why it’s worth it

GitOps gives you four things that are hard to get otherwise: a single source of truth that’s actually enforced, drift correction without firefighting, an audit trail that’s just your Git history, and rollback that’s a revert. The cost is a real shift in workflow — you stop running apply and start trusting a controller.

Start small: put one non-critical environment under a controller, turn on self-heal, and watch it correct a deliberately-introduced drift. Once you see reality snap back to Git on its own, the model sells itself. Keep your review prompts in a prompt library, respect prune, and let Git become the control plane.