Version the Network: GitOps for Routing Policy

1. Introduction: Routing Policy Is Production Code

It’s surprising how often we forget that routing policy (the knobs, filters, and maps that determine the very behavior of our networks) is the thing that actually runs our infrastructure.

We obsess over our applications and code pipelines, building test harnesses for every minor UI toggle. We wrap everything in continuous integration and version control.

But routing policy?
Prefix lists?
AS-path filters?
ACLs that block or permit entire traffic classes?

Too often, we treat those as… ad-hoc config snippets. Handcrafted, untracked, and unreviewed. Worse: often edited live during a change window by the one engineer “who knows that device.”

We’ve spent decades advancing how we build, test, and ship code. Isn’t it time we gave network policy the same level of discipline?

The fact of the matter is that: Routing policy is production code.

In many organizations, it may not live in a repository (yet), but it absolutely shapes your users’ experience, every single day.

The Danger of “Just Edit It Live”

In too many environments, here’s how network changes still happen:

• An issue is reported (or predicted).

• A senior engineer opens a terminal.

• A prefix list or route map is modified directly on the box.

• A second engineer monitors Slack to identify any issues that may arise.

• If something does break… well, hopefully they saved the last version somewhere.

There’s no version control, no changelog, no clear rollback, and no system-wide understanding of what was touched, where, and why.

This might work for a lab, or a small branch office. But at hyperscale? Where one policy change can affect hundreds of devices, or tens of thousands of prefixes?

It’s a ticking bomb.

Time for a Better Model

We need a system where:

• Every routing policy is declared, versioned, and reviewed before deployment.

• CI pipelines simulate impact, validate correctness, and compare intent vs actual.

• Deployments occur automatically and safely, eliminating the need for manual SSH sessions.

• Rollbacks are not guesswork, but Git reverts.

• And policy logic is no longer tribal knowledge; it’s structured, documented, and testable.

This may look like science fiction, but I assure you that it's not. It's the way we develop application infrastructure nowadays. Now, we’re applying these same principles to networking.

In this article, we’ll explore how to apply GitOps to routing policy. Not just “configs in Git”, but real operational transformation, with pipelines, validation, and automation that let your network evolve safely, quickly, and at scale.

Let’s begin by examining the current (and painful) state of routing policy in most networks today.

Subscribe to our premium content to read the rest.