Managing change is hard, especially when you’re responsible for infrastructure.
The developer mantra of “Move fast and break things” made famous by Facebook would absolutely tank an operations team responsible for keeping systems steady.
Changes in our world, even small ones, carry high risk. Who hasn’t heard the stories of one keystroke error that took down an entire network for hours or days?
Yet software engineers wouldn’t dream of working without a version control safety net in place.
So why have infrastructure teams been operating without one for so long, when the risk of a fall is so much higher?
And what does version control that specifically addresses the needs of infrastructure management truly look like?
Let’s have a look.
Git alone can’t support version control for infrastructure
When you hear the words “version control,” do you immediately think of Git? Many people do, and it’s easy to see why.
For the last 20 years, Git has been a phenomenal tool for helping software developers safely track, review, and deploy code. Git and its CI/CD pipeline are now foundational pieces of a mature DevOps or GitOps practice.
But infrastructure isn’t code, as much as we’d like to treat it that way.
It would be great to use the same Git-supported versioning options that software devs have for code, but the reality is that it isn’t so easy for us.
Managing and automating infrastructure means working with a lot of structured data—such as devices, interfaces, and policies—and all of the complex relationships between those things. You need a database for managing that kind of data.
Git isn’t a database. It sees files, not relationships. It can’t validate that a VLAN is properly linked to a switch interface or that an IP address change won’t break a downstream service.
When configs are stored in Git as YAML or JSON files, and there’s no schema or UI, querying that data is painful. Answering “What was connected to this customer’s service three months ago?” requires grepping through old text files instead of asking the system directly.
Let’s be clear: The GitOps principles of branching, peer review, and change history are tremendously powerful. They work beautifully for the code development process they were designed by Linus Torvald to handle.
These Git-enabled processes can, and absolutely should, be a part of version control for infrastructure. But there needs to be more to version control if we want it to handle the unique needs of infrastructure management and automation.
What does true version control for infrastructure look like?
Version control that’s suitable for managing infrastructure starts with acknowledging that infrastructure data isn’t just a collection of static text files. It’s structured, interdependent, and constantly changing. And it lives in a database.
Any serious version control approach for infrastructure must therefore start by working seamlessly and natively with that database.
- Structured data model, not just files: Devices, interfaces, policies, and their relationships need to be modeled in a way that can be queried and validated easily. Treating them as raw text files ignores these connections
- Schema evolution support: Infrastructure data models change over time with new device types, new attributes, new services. Version control must safely handle these schema changes.
- Complete change history: You need to know who made a change, when, and why. That detail supports rollbacks, compliance audits, and faster root-cause analysis.
- Built into the platform itself: Version control can’t be an afterthought or bolt-on. It needs to be core to how the platform stores and manages data to prevent drift and ensure consistency.
Once our version control accounts for the practical reality of working with a database instead of static code files, we can then bring back the Git practices that previously didn’t fit with infrastructure.
- Branching and merging: Experiment in isolation, validate changes, and merge them back safely once approved. This reduces risk while encouraging speed.
- Collaborative reviews: Engineers can comment on proposed changes, ask questions, and approve or reject them. Real-time peer review replaces slow ticket-driven approvals and change advisory boards.
- Integrated testing and CI/CD: Every change can trigger automated checks to enforce standards and catch problems early, turning validation into a built-in safety net.
Together, these database-centered and Git-like capabilities create a version control that maps to the specific realities of infrastructure teams.
We no longer need to borrow from DevOps and try to shoehorn our practices into theirs.
We can move with all the speed and agility of the DevOps pipeline but without sacrificing our structured schema, data dependencies, or query functions.
Why infrastructure version control matters even more with AI
A future is coming where AI will play a significant role in monitoring, managing, and automating infrastructure. For example, AI might propose changes that optimize cloud resources, rebalance network traffic, or turn off an unused WAN circuit.
In this future (which isn’t so far away) a reliable version control system will be critical for giving AI guardrails: a way for AI-generated changes to live in a branch, be reviewed like any other change, and merged only after humans and automated checks sign off.
One more thing about infrastructure version control
We've talked about the technical components of version control. But there's one more important realization: You can now apply version control to everything you do with infrastructure.
Infrastructure teams have been practicing many of the principles of version control all along. Think about it. CABs are essentially peer review. Change documentation is your commit history. Rollback procedures are your revert strategy.
You’ve been doing version control. You've just been doing it manually, with spreadsheets and committee meetings instead of purpose-built tools. And because this approach is so time-intensive, you've had to be selective about when and where to use it.
Now you finally have the technology to make version control a default practice at every step. You can manage risk just like you've always done, while keeping up with the speed the business demands.
With true version control for infrastructure, you have the tools to match your collaborative mindset and be as agile as you want to be.
