Infrahub: a graph-based source of truth with version control for infrastructure data

A source of truth whose data is version controlled

Infrahub is described as a graph-based data management platform with built-in version control, CI workflows, peer review, and API access, purpose-built to power reliable infrastructure automation at scale. The README calls it the data foundation for modern infrastructure automation, for teams managing networks, data centers, and cloud infrastructure.

The stated move is from fragmented data and one-off scripts to repeatable, validated workflows, delivering infrastructure as a reliable service to the rest of the business and to the AI agents that consume it.

The key capability is the second bullet. Version control for data, not just configs. Branches, peer review, and a complete queryable history of who changed what, when, and why, applied to schema, data, and generated artifacts.

That is the idea the rest of the product rests on. In most infrastructure tooling, the source of truth is a database that gets edited directly and the configuration that is generated from it lives in Git. Here the data itself is in Git-like workflows, so a change to a device's interface is branched, reviewed by a peer, validated in CI and merged.

The first capability sets the model. A schema-first, graph-backed data model, where you define your own data models for devices, services, topologies, and business context, enforced with validation and queried with first-class relationships on a Neo4j graph database.

So there are two halves. The schema is the type system, and the graph is the store. Neo4j is a named dependency in the package manifest at a pinned version, along with neo4j-rust-ext, which is the Python extension Neo4j needs to talk to the database efficiently.

The Python package manifest names the runtime dependencies that make the graph and the workflow work.

    "neo4j==6.2.0",
    "neo4j-rust-ext==6.2.0.0",
    "pydantic>=2.12,<2.13",
    "pydantic-settings>=2.10,<3.0",
    "prefect==3.8.6",
    "prefect-redis==0.2.15",
    "Jinja2>=3,<4",
    "gitpython>=3.1.50,<4",

The primary language is Python, the licence is Apache-2.0 with a LICENSE.txt file at the root, the default branch is stable, and the last push was on 2026-10-20 with releases infrahub-v1.11.8 from 2026-10-19, v1.11.7 and v1.11.6.

Generators turn data into configuration, and the outputs are testable

The third and fourth capabilities are what make the platform more than a database with a nice UI.

Generators and transforms: render configurations and other artifacts from Infrahub data using Jinja2 or Python, composable, reusable, and version-controlled alongside the data.

Built for production: templates and generators are unit-and-integration testable. Every change moves through branch, then CI, then review, then merge, and idempotent re-runs surface and correct deviations without a full rebuild.

The Jinja2 mention is the concrete detail. Jinja2 is in the dependency list at Jinja2>=3,<4, and it is the same templating language Ansible uses, which is not a coincidence given the integrations. If your existing templates are Jinja, they can render from Infrahub data rather than from Ansible variables.

The idempotency claim deserves attention because it is where infrastructure tooling usually falls apart. A generator that runs against the current data and produces what is already deployed should be a no-op, and a generator that produces something different should show the deviation and correct it. Running it again should not thrash the network. The README claims that behaviour, and it is the property that makes re-running on every merge safe.

The unit and integration testability point is the other half. If a generator is a testable unit, you can assert on what it renders before it ever touches a device, which is the difference between infrastructure as code and infrastructure as a series of manual steps with a script at the end.

The dependency list backs the workflow claim. Prefect at 3.8.6 with prefect-redis is the workflow engine behind the pipelines, and GitPython at 3.1.50 or newer is the Git layer behind the branching and history.

GraphQL, REST and connectors are how the data gets out

The integrations capability is the one that decides whether Infrahub becomes the system everything else talks to, or another island.

Connectors for Git, Ansible, and Nornir. Infrahub Sync federates data from Netbox, Nautobot, and IP Fabric. GraphQL, REST, and a web UI back service catalogs so internal teams and customers can self-serve.

The three API surfaces are a deliberate choice rather than a leftover. GraphQL is what an application asks when it wants a graph traversal, and a graph database with a relational-style query layer would waste the main advantage of the storage model. REST is there for the straightforward cases and for integrations that do not speak GraphQL. And the web UI over the same data is what turns Infrahub from a tool the network team uses into a self-service catalog that application teams consume.

The dependencies match. Graphene at 3.4 or newer is the GraphQL library, FastAPI at 0.141.1 is the API server, and gunicorn with uvicorn is the serving stack. The GraphQL machinery in the manifest is what implements the GraphQL surface.

The connectors are a different kind of feature. Git, Ansible and Nornir connectors mean Infrahub is not asking you to abandon your existing automation. The Sync feature federating from Netbox, Nautobot and IP Fabric is the migration path: you point it at the source of truth you already have and it imports rather than making you re-enter everything.

The last integration is the one that is new enough to be worth naming separately. An MCP server and Infrahub Skills make Infrahub's validated, relationship-rich data directly usable to Claude, Cursor, and other AI agents. That is what the phrase about delivering infrastructure to the AI agents that consume it refers to in practice.

Trying it comes in three flavours, and two of them need nothing installed

The Getting started section offers three routes, and the ordering tells you what the maintainers would like you to do first.

The Sandbox is a hosted demo of the Infrahub UI with sample data, so you can explore the interface without installing anything. The Getting Started Lab is a guided browser tutorial covering branches, schemas, and unified storage. The Quick Start guide sets up a local Infrahub instance and walks through the basics in your own environment.

So the browser comes first and the local install comes third, which is the right order for a platform this size. The Lab is the one to start with if you want to understand the branch and schema model, because a full read of the documentation before you have seen the shape of the data model is a poor use of an afternoon.

For production deployments on Kubernetes, the README points to the opsmill/infrahub-helm repository and the installation guide.

That matters because Infrahub is not a single container. The compose file in the repository shows the configuration surface, and it is large: the environment variable block includes DB_TYPE defaulting to neo4j, the INFRAHUB_ADDRESS, an INFRAHUB_ALLOW_ANONYMOUS_ACCESS defaulting to true, an INFRAHUB_ANONYMOUS_ACCESS_ROLE defaulting to Anonymous User, a set of AWS and S3 settings for object storage, and a detailed group of INFRAHUB_API_BACKPRESSURE_* variables with names like INFRAHUB_API_BACKPRESSURE_BACKSTOP_HIGH_MULTIPLIER, INFRAHUB_API_BACKPRESSURE_MAX_CONCURRENCY_FACTOR and INFRAHUB_API_BACKPRESSURE_CODEL_TARGET_SECONDS.

Those backpressure knobs are a telling detail. They set explicit targets for request concurrency and code delay, which is the kind of configuration that only appears in a product whose API is meant to sit in the path of many automated clients. It also tells you the API is expected to be rate limited deliberately rather than left to whatever the web server does.

The whole configuration surface is documented separately at the configuration reference, and the compose file points there for details. The first lines of that block look like this.

  DB_TYPE: ${DB_TYPE:-neo4j}
  INFRAHUB_ADDRESS:
  INFRAHUB_ALLOW_ANONYMOUS_ACCESS: ${INFRAHUB_ALLOW_ANONYMOUS_ACCESS:-true}
  INFRAHUB_ANONYMOUS_ACCESS_ROLE: ${INFRAHUB_ANONYMOUS_ACCESS_ROLE:-Anonymous User}
  INFRAHUB_API_BACKPRESSURE_CODEL_TARGET_SECONDS: ${INFRAHUB_API_BACKPRESSURE_CODEL_TARGET_SECONDS:-0.005}

Every one of those names is a setting you can override in your own environment, and the defaults are the ones shown.

The ecosystem around it is where the day to day work happens

The README maintains a table of officially supported projects, split into two groups, and the split tells you what stage of adoption you are at.

For developing with Infrahub there is infrahub-sdk-python, the Python SDK and the infrahubctl CLI, for building integrations and managing Infrahub from code; infrahub-vscode, a VS Code extension with schema validation, GraphQL query support and schema visualization; the Infrahub Marketplace, a curated catalog to scaffold your instance, currently schemas and schema collections; infrahub-mcp, the MCP server exposing Infrahub data to Claude, Cursor and other AI agents; and infrahub-skills, AI skills that give coding assistants knowledge of Infrahub conventions and data models.

For running Infrahub in production there is infrahub-helm, the Helm charts for deploying on Kubernetes, and infrahub-backup.

The Marketplace entry is worth a second look, because its scope is limited. It currently holds schemas and schema collections, meaning the scaffold is of the data model rather than of whole workflows or templates. If you are expecting a catalog of ready-made integrations, that is not what it is yet.

The two AI projects are a matched pair and they are interesting. The MCP server gives an agent access to the data, and the skills give the agent knowledge of the conventions and data models. One without the other is not much use, since an agent that can query the graph but does not know how the schema is shaped will produce confidently wrong queries.

The repository layout also reflects a project of this size. There is a backend/ and a frontend/ for the two halves of the application, a docs/ directory, a schema/ directory holding the schema definitions, a models/ directory, a python_sdk/ directory, python_testcontainers/, tasks/, utilities/, tests/, and development/ and dev/ directories. There are also .devcontainer/, docker-compose.yml, a flake.nix and uv.lock for the toolchain, a pyproject.toml, and a pre-commit-config.yaml alongside .yamllint.yml and .vale.ini for the documentation linting. The AGENTS.md and CLAUDE.md at the root, plus a .claude/ directory and a skills-lock.json, show that the project has been set up for AI-assisted development of its own codebase, which is a reasonable thing for a project that ships AI tooling.

Where Infrahub is the wrong tool

The first wrong-tool case is a team that wants a source of truth but not a platform. Infrahub is not a lightweight IPAM or a device inventory with a search box. It is a Python API server with FastAPI, GraphQL via Graphene, a Neo4j graph with a Rust extension driver, a Prefect workflow engine, Redis, object storage, and a Git layer for data versioning. That is a substantial deployment, and a team with ten switches in one room does not need it.

The second case is a team whose problem is configuration drift rather than data sprawl. The platform's value is in the graph and the workflow, and if your pain is that the running devices disagree with the intended configuration, a generator that renders and diffs is enough.

The third case is an environment where the data cannot live in Git-like workflows. The whole model depends on people being willing to branch, review and merge infrastructure data. Some regulatory or operational contexts require a change to a live network to happen under a ticket rather than a pull request, and a tool whose core loop is the pull request is then the wrong shape.

There is an edition split to factor in, and the README links the community versus enterprise documentation directly in the header. Infrahub Community and Infrahub Enterprise are separate offerings, and the sandbox link sits beside them. Before evaluating capability you need to establish which edition you would be running, because the two are not the same product and the README does not spell out the boundary.

On the technical side, the dependency pins are tight and that cuts both ways. FastAPI is pinned to 0.141.1, Prefect to 3.8.6, neo4j to 6.2.0, redis with hiredis to 6.0.0, and pydantic to a narrow range. A project where the version floor is Python 3.12 with an upper bound of 3.15 means the supported interpreter range is narrow by design, and the pins mean you are picking up upgrades on the maintainer's schedule rather than your own.

One deployment detail to note. The compose file sets INFRAHUB_ALLOW_ANONYMOUS_ACCESS to true by default, with a role name of Anonymous User. That is a sensible default for a local evaluation and an alarming one in production, so it is worth checking what the Helm charts set instead.

On licence, the project is Apache-2.0, and the manifest declares the same. The code is open, the operation of the platform as a service is where the community and enterprise editions differ, and the second half of the README, listing the ecosystem and infrastructure providers, is where that commercial story starts.

Editorial conclusion

Infrahub suits a team whose network source of truth is a spreadsheet plus a set of scripts and who want the data itself to be version controlled and reviewable, because the branch, CI, review and merge model applies to schema and data rather than only to configuration. It does not suit a team that wants a lightweight IPAM or a device inventory, since the platform is a large install with a graph database and a Python API server. Before adopting, try the Sandbox and the Getting Started Lab before running anything locally, and read the community versus enterprise documentation first, because the edition split determines which capabilities you actually get.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. opsmill/infrahub on GitHub
3. Project website
4. README
5. Releases