Originally published on aniljaiswal.com.
The GitOps demo is gorgeous. One repo, one app, one cluster. You change a value in Git. A few seconds later, the cluster changes to match. Production is a commit hash. Rollback is a git revert. Everyone in the room nods, and you roll it out.
Two years later, you have 200 repos, 40 teams, and four environments. The beautiful model is groaning. The ArgoCD controller is pegged. Someone hotfixed prod with kubectl three weeks ago, and nobody noticed until the next deploy quietly reverted it. A team deployed into another team's namespace by accident. Promoting a change from staging to prod means copy-pasting YAML between folders and praying. And every change, even a one-line config bump, is now a pull request waiting on a review.
None of this means GitOps was the wrong call. It means GitOps is a distributed system like any other. The simple setup that works for one team does not survive forty. The principles hold. The shape has to change. Here is what breaks as you scale, roughly in the order it bites, and how to fix each part.
The control plane melts before you notice
