Infrahub: Git for Infrastructure State, Built as a Graph
A deep look at how OpsMill turns branches, diffs, and schema changes into a single source of truth for automation, validation, and change control.
- Infrahub’s key move is to make infrastructure state branchable, diffable, and mergeable at the data layer itself.
- The graph model matters because infrastructure is defined by relationships, not just rows or files.
- Its diff and merge pipeline treats schema changes as first-class events, which is what makes temporal change control possible.
- Infrahub is less a storage tool than a platform for infrastructure change, validation, and automation.
Infrahub is not trying to be another inventory database. It is trying to make infrastructure state behave like code without flattening away the relationships that make infrastructure hard in the first place. That is a sharper idea than it first sounds, because the product is really about change control over a living graph.
The branch is the product
Most teams know the Git idea. Infrahub takes that instinct and applies it to infrastructure data itself. Branches are not an external wrapper around state. They are part of the model, which means the system can reason about data changes and schema changes in the same flow.
With built-in version control, flexible schema, and native CI integration, it solves the scaling and maintenance issues of existing solutions—so your automation can go further, faster.
That quote lands because it matches the repo’s shape. Infrahub is built around a graph core, a FastAPI surface, and a diff engine that understands time. The branch is not a metaphor pasted on top. It is the product’s organizing principle.
Why inventory files stop scaling
Static YAML, spreadsheets, and ad hoc scripts work until they do not. They can describe state, but they do not make state easy to validate, compare, or evolve. Once the infrastructure model starts changing as quickly as the infrastructure itself, the truth gets split across files, pipelines, and tribal knowledge.
| Approach | What it stores | How it changes | Where it breaks |
|---|---|---|---|
| Static inventory files | Text snapshots of devices and config | Manual edits plus CI glue | Schema drift, brittle automation, weak validation |
| Traditional SoT tools | Current structured state | Database updates without native branching | Harder to model temporal change and schema evolution |
| GitOps plus scripts | Configuration text in Git | PRs, pipelines, custom reconciliation | State and relationships are scattered across tools |
| Infrahub | Versioned relational infrastructure state | Branch, diff, merge, validate inside the model | Requires adopting a new data model, but keeps structure intact |
The important distinction is not files versus databases. It is text versus structured, versioned relational state. Infrahub is built to preserve the structure that automation needs while still giving teams the familiar control surface of Git-like workflows.
A graph where every device, VLAN, and relationship is a node
Infrahub’s schema layer is the real unlock. The backend treats infrastructure as graph primitives: nodes, attributes, and relationships. That is a better fit for infra than a fixed table because the interesting part is rarely the object alone. It is how objects depend on each other.
A VLAN belongs to a device. A service depends on a subnet. A policy applies across environments. Those edges are not metadata. They are the system. Once the schema itself is flexible, Infrahub can model those links without forcing every change through a database migration first.
The diff engine does more than compare snapshots
This is where Infrahub stops looking like a database with Git polish and starts looking like a real change-management system. The coordinator does not just ask what changed between two states. It asks what changed over a time window, what those changes depend on, and whether the schema still agrees with the data.
# Conceptual flow, simplified from Infrahub's diff/merge pipeline
coordinator = DiffCoordinator()
diff = coordinator.build(
base_branch="prod",
target_branch="feature/new-vlan-model",
from_time=start_ts,
to_time=end_ts,
)
# Raw deltas become enriched with relationships, metadata, and schema context
enriched = DiffEnricher().enrich(diff)
locked = DiffLocker().lock(enriched)
merged = DiffMerger().merge(locked)
That sequence matters. The calculator finds raw deltas. The enricher adds context so the system knows what those deltas mean. The locker prevents inconsistent concurrent updates. The merger then applies changes in batches, including node kind migrations when the schema itself has evolved.
In other words, the diff is not just a comparison. It is a policy surface for deciding what kind of change is safe to apply.
Data extensibility is non-negotiable because the source of truth needs to store all the information about your infrastructure at multiple levels (technical, design) and it also needs to capture all the services that are exposed to the customers/users and it needs to adjust to the business specific needs and requirements.
What Infrahub is really competing against
Infrahub is often compared to NetBox, Nautobot, and GitOps workflows, but the more useful lens is simpler: what kind of truth does each system store? NetBox and Nautobot are strong structured inventories. Git stores text. GitOps stitches those pieces together with automation. Infrahub is trying to sit in the middle as versioned relational state.
| System | Primary model | Versioning | Best at | Trade-off |
|---|---|---|---|---|
| NetBox / Nautobot | Structured inventory | Mostly current state | Fast source-of-truth workflows | Less native branching across evolving models |
| GitOps + YAML | Text in Git | Strong file history | Reviewable config change | Weak relational semantics and validation |
| Custom app + DB | Whatever the team builds | Optional and expensive | Tailored workflows | Maintenance cost rises fast |
| Infrahub | Versioned graph state | Native branches, diffs, merges | Change control across data and schema | Requires adopting graph-native modeling |
That distinction is the whole argument. Infrahub does not replace Git. It absorbs the data problems Git cannot solve on its own, especially when relationships, validation, and schema drift matter as much as the content itself.
Why the architecture matters for AI and automation
The repo’s AI angle is not decorative. A structured graph is easier to query, validate, and reason over than a pile of config files. That matters for automation because policy checks can traverse dependencies directly, and it matters for AI because the model has real relationships to work with instead of just text blobs.
The codebase also hints that OpsMill is dogfooding automation internally, including bug-agent style workflows in CI. That is a subtle but important signal. The product is not only for humans who manage infrastructure. It is also for systems that need reliable, machine-readable state to act on.
The larger bet is that infrastructure platforms should behave more like operational data systems than file sync tools. Infrahub makes that bet explicit. It turns change control into a first-class graph operation, and that is what makes it interesting.
