"The configuration is on the device itself, isn't it." True, until the device dies. Or until nobody remembers why that one ACL rule is there, who added that VLAN, and whether the situation on the switch still matches the documentation. The configuration of a router or switch is code: lines of text that determine what your network does. But where software has lived in version control for ages, network configuration often still hangs somewhere between the device itself, an outdated text dump and an administrator's memory.
What goes wrong without it
- Replacing becomes rebuilding — when a switch fails, its configuration has to come from somewhere. Without a current archive that means reconstructing from old dumps, screenshots and memory, in the middle of an outage.
- "Who changed this, and why?" — the first question at every piece of strange behaviour, and unanswerable without history.
- Documentation and reality drift apart — what you think is running and what is running are two different things, and you discover the difference when it hurts.
Every change a commit
We solve this by automatically recording the configuration of all our network equipment in git; the open-source tool Oxidized logs into each device periodically and retrieves the running configuration. The essential part is what happens next: a commit is only created when the configuration has actually changed. The history is therefore not a pile of nightly copies but a logbook of real changes, each with a timestamp.
- Diffs instead of dumps — you see not just that something changed but what: those two lines in the ACL, that one extra VLAN. Laying two full configurations side by side is never needed again.
- Recovery in minutes — a replacement device gets the last known configuration, not a reconstruction.
- Changes that stand out — a commit that does not belong to an announced change is immediately visible. That catches the forgotten manual tweak, and in the worst case a change none of us made.
Why git, and not a backup folder
A folder of dated text dumps stores the same thing and still answers nothing: which of the forty files differs from yesterday's, and where? Version control is built for exactly those questions; history, differences and provenance are its core functions, not something you script around it. It also matches how we set up everything else: our policies and ISMS already live in git, with the same audit trail. Configuration, software and policy end up with a single answer to "what changed, and when".
The first question in every outage
"What changed?" is the opening question of every incident investigation. Without version control the answer is a guess; with version control it is a log entry, found within a minute. And for anyone who has to demonstrate that change management is in order, to an auditor or under the NIS2 duty of care, the archive itself is the evidence: every change to the network, recorded at the moment it happened.
This is how we run our network
This is not a service we sell but the way we work: the network behind our colocation and IP transit is managed this way, as is the management access to it. Want to know what that means for the infrastructure your equipment or traffic runs on: get in touch.