GitOps for network infrastructure: where it works and where it doesn't

GitOps has a simple, attractive promise: the desired state lives in Git, an agent reconciles reality to it, and drift becomes visible and correctable. For Kubernetes this works because the platform is designed around declarative reconciliation. Networks are not, and that difference is the whole conversation.

The core idea, and its prerequisite

GitOps needs three things to be more than a slogan:

1. A source of truth that describes the intended state of the network.
2. A reconciler that can read that intent and push it to devices idempotently.
3. A feedback loop that detects drift and reports or corrects it.

Point two is where most network GitOps efforts live or die. If your “reconciler” is a pipeline that renders config and applies it once per merge, you do not have continuous reconciliation — you have CI/CD with a Git history. That is still valuable, but it is a different thing.

Where it works well

• Configuration that is genuinely declarative. Interfaces, VLANs, routing intent, ACL policy — things you can render from data and apply idempotently.
• Greenfield or standardised fleets. When the devices and roles are uniform, a single intent model maps cleanly.
• Platform-adjacent networking. Anything that already lives in Kubernetes (ingress, load balancers, policy) benefits from the same flow.
• Validation as a gate. Even without a continuous reconciler, Git-as-source-of-truth plus pre/post validation is a large improvement.

Where it fights you

• Stateful, imperative operations. Some changes are not declarative: a software upgrade, a card swap, a one-way migration step. GitOps has no clean way to express “do this once, in this order.”
• Brownfield reality. Device-by-device differences, legacy features and accumulated drift mean your intent model has to tolerate exceptions. Every exception is a maintenance cost.
• Partial APIs. If half your intent is only configurable via CLI, the reconciler cannot close the loop, and you are back to rendering-plus-apply with a human in the middle.
• Blast radius. A reconciler that can change anything can break anything. Automated reconciliation demands stronger validation and a careful review model, not less.

A pragmatic middle ground

Most successful network GitOps looks like this:

• Git holds intent, expressed as data, not as rendered CLI.
• A pipeline renders and validates on merge, and applies in controlled stages.
• Telemetry and periodic checks detect drift, even if correction stays manual.
• Continuous reconciliation is reserved for the subset of config where it is safe and the API is complete.

That is honest about the constraints. It gets you reviewability, history and validation — the parts that pay off immediately — without pretending every device is a Kubernetes node.

The test to apply

Before adopting GitOps for a domain, ask:

• Can I express this as intent, not commands?
• Can I apply it idempotently?
• Can I detect drift and prove convergence?

If the answer is yes to all three, GitOps fits. If it is yes to the first two, you have excellent CI/CD and a strong source of truth — and that is worth having on its own. Knowing the difference keeps you from chasing a model the network cannot actually support.