OpsMill raises $14M Series A for Infrahub, a version-controlled graph database designed to be the
What "Infrastructure-as-Data" Actually Means
Most infrastructure automation treats configuration as files: YAML manifests, Terraform state, spreadsheets, and wiki pages that drift apart the moment someone edits one without the others. Infrahub, the product behind OpsMill's $14M Series A, reframes the network and infrastructure layer as data first. Instead of scattering the truth across tools, it stores devices, interfaces, circuits, IP addresses, and their relationships in a single graph database that other systems query and update.
The graph model matters because infrastructure is relational at its core. A change to one VLAN touches switches, firewalls, and routing policy; a graph captures those dependencies natively rather than forcing you to reconstruct them by joining flat records. That structure becomes the input for generating device configs, validating changes, and answering questions about what connects to what.
Why Version Control Changes the Workflow
The other half of Infrahub's design is treating the source of truth like a codebase. Because the data is version-controlled, you can branch it, propose changes in isolation, review a diff, and merge—the same loop engineers already use for application code. A proposed network change lives on a branch until it is validated and approved, instead of being applied directly to a live system and hoping nothing breaks.
This gives teams a few concrete capabilities that are hard to get from a static database or a pile of config files:
- Diffs that show exactly what a proposed change alters before it reaches production.
- Branches so multiple changes can be developed in parallel without stepping on each other.
- An audit trail that ties every state of the infrastructure to who changed it and why.
- The ability to roll back to a known-good version when something goes wrong.
Why This Fits AI Agents
The framing that Infrahub is built for AI agents follows directly from the two ideas above. An agent acting on infrastructure needs a reliable place to read the current state and a safe place to write proposed changes. A queryable graph gives the agent structured context—not free-form text it has to parse—so it can reason about dependencies. Version control gives the agent a sandbox: it can open a branch, make edits, and submit them for validation and human review rather than mutating live systems directly.
That separation is the practical safety mechanism. An agent's output becomes a reviewable proposal with a visible diff, checked against the same rules a human change would face. If the agent gets something wrong, the change is caught at the branch stage or rolled back, not discovered after an outage.
How to Evaluate It for Your Stack
If you are considering this model, start by asking where your current source of truth actually lives and how often it drifts from reality. Infrastructure-as-data pays off most when you have enough relationships and enough change velocity that spreadsheets and one-off scripts have stopped keeping up. Map out which systems would read from the graph and which would write to it, since the value depends on real integrations, not just storing data in a nicer shape.
Then treat the version-control workflow as the thing to pilot. Run a low-risk category of change—say, IP address assignments or a single site—through the branch, review, and merge loop before handing any of it to an automated agent. Prove the review gate works with humans first; the agent-driven case is the same workflow with a faster author.