GitOps Changed How I Think About Infrastructure

I used to SSH into servers and run commands. Ansible was an improvement — at least changes were repeatable. But GitOps fundamentally shifted my mental model.

The Old Way

SSH in. Run a command. Hope you remember what you did. Maybe write it down somewhere. Probably forget to update the docs.

The Git Way

Every change is a commit. Every commit is reviewed. Every review is documented. The repo is the cluster state.

“The repo is the cluster” isn’t just a slogan — it’s a constraint that prevents entire categories of mistakes.

FluxCD in Practice

Flux watches your git repo and reconciles the cluster to match. Push a change, Flux applies it. Delete a manifest, Flux removes the resource. It’s beautifully simple.

The real win isn’t automation — it’s auditability. When something goes wrong, git log tells you exactly what changed and when. Try doing that with kubectl apply history.

The Hard Part

The hardest part of GitOps is discipline. It’s so easy to kubectl patch something “just this once.” Don’t. The moment you make one ad-hoc change, you’ve broken the contract.

I learned this the hard way when a direct kubectl change caused a Helm field manager conflict that took down our Postgres database. That was the last time I touched kubectl apply in production.