Where the sprawl actually accumulates
Each new service, environment, and region multiplies the manifests needed, and without a templating or overlay strategy, teams end up hand-copying and lightly modifying YAML across dozens of near-duplicate files — the exact manual, error-prone pattern GitOps was supposed to eliminate, now living inside the GitOps repository itself.
This is recognisable as the same problem configuration management faced before GitOps existed; GitOps moved the problem, it didn't eliminate it.
What keeps the repository itself manageable
A templating or overlay tool (rather than hand-copied YAML), a clear structure separating base configuration from environment-specific overrides, and periodic pruning of unused manifests keep the GitOps repository itself from becoming the next thing that needs a tool to manage it.
GitOps fixed configuration drift. It didn't fix configuration sprawl — that's a separate discipline, applied to the GitOps repo itself.MNB DevOps Practice
Key actions
- Use a templating or overlay tool instead of hand-copied manifests
- Separate base configuration from environment-specific overrides clearly
- Prune unused manifests on a regular cadence
- Treat the GitOps repository itself as something needing active configuration management