Introduction
GitOps has moved from buzzword to standard practice for many teams deploying to Kubernetes. The core idea, using Git as the single source of truth for declarative infrastructure and applications, is elegant in its simplicity. But most tutorials stop at the "hello world" stage: one repository, one cluster, one environment.
When you scale GitOps to dozens of repositories, multiple environments, and cross-team governance, the challenges change fundamentally. This post shares what we have learned helping teams navigate that transition.
The Governance Gap
In a single-team, single-cluster setup, GitOps is straightforward. Push a manifest change, watch it sync. The problems emerge when you need to answer questions like: Who approved this change? Does this deployment comply with our security policies? Can this team modify resources in this namespace? How do we enforce consistent configurations across 40 clusters?
Policy as Code
The first pillar of GitOps governance is policy-as-code. Tools like OPA (Open Policy Agent) and Kyverno allow you to define policies that are evaluated automatically, either at admission time in the cluster or as part of your CI pipeline before changes are even merged.
- Enforce resource limits and requests on every deployment.
- Require specific labels and annotations for cost allocation and ownership tracking.
- Block images from untrusted registries or without vulnerability scans.
- Ensure network policies are defined for every namespace.
Repository Structure at Scale
The mono-repo versus multi-repo debate takes on new dimensions with GitOps. Our recommendation: use a layered approach. Application teams own their deployment manifests in their own repositories. A central platform repository defines cluster-wide configurations, policies, and shared infrastructure. An overlay mechanism, whether Kustomize or Helm values, stitches these layers together per environment.
Audit and Compliance
One of GitOps' underappreciated strengths is its built-in audit trail. Every change is a Git commit with an author, timestamp, and approval chain. This maps directly to compliance requirements like SOC 2 and ISO 27001 change management controls. The key is to configure your GitOps tooling to capture and surface this data in a way auditors can consume.
Conclusion
GitOps at scale is less about the tooling and more about the processes you wrap around it. Policy-as-code, structured repository patterns, RBAC alignment, and audit-friendly workflows transform GitOps from a deployment mechanism into a governance platform. At CaeliCode, we help teams design these patterns so they can move fast without sacrificing control.