Over the last several months, I’ve come to learn that every new customer conversation about Infrahub follows a familiar arc. It starts with the day-to-day reality of running infrastructure at scale, and ends with a very reasonable question: Can we actually do this in production?
This post walks through that arc, from the operational pain that brings teams to Infrahub, to the architectural and production-readiness questions that follow.
The operational reality
The teams we talk to aren’t browsing for new tools out of curiosity. They’re dealing with real, compounding pressure.
Network inventory is scattered across spreadsheets, legacy CMDBs, Slack threads, and tribal knowledge. Nobody fully trusts the data. Automation exists, but it’s brittle. Scripts break when the underlying data drifts, and engineers spend more time fixing automation than using it. Every change carries production risk, and the review processes meant to catch problems are informal, inconsistent, or missing.
Meanwhile, the business expects network resources on demand: VLANs, IPs, firewall rules, new services. Ticket queues are no longer acceptable. Device counts and service complexity keep growing, but team sizes stay flat. The gap between what teams manage and how they manage it widens every quarter.
This isn’t an automation problem. It’s a data problem. CMDBs weren’t built for automation. Git repos with YAML files can’t model real infrastructure relationships. Custom in-house builds fit perfectly…until the author leaves and the whole thing becomes unmaintainable.
Teams need a platform that combines a trusted data foundation, DevOps-grade change workflows, and the flexibility to model infrastructure the way it actually works. That’s what Infrahub is.
What Infrahub changes
Infrahub is a unified data management platform with built-in version control, purpose-built for infrastructure automation. It gives teams a trusted, schema-enforced source of truth with graph-native relationships; branch-based proposed changes with peer review, CI validation, and full audit trails; Generators that turn trusted data into configs, cable plans, and deployment artefacts; and a GraphQL API and integration layer that connects to any orchestration or deployment tool in your stack.
The result is a shift in operating model: from fragmented data and manual processes to trusted, validated, repeatable delivery. One European service provider reduced service deployment time from 120 hours to under 15 minutes after moving to schema-driven automation with Infrahub. Another enterprise expanded from one to five data centres, managing multi-vendor deployments through a single trusted data platform.
Once teams see the vision and start building in the lab, the conversation naturally shifts. The next questions are about production.
Can Infrahub support our infrastructure?
This is usually the first production question, and rightly so. If you’re managing thousands of devices across multiple regions, you need to know the platform can handle the dataset and query patterns your automation depends on.
Infrahub is a single platform with a common core. The Community edition is a good fit for teams getting started, running labs, or operating at moderate scale. As deployments grow—particularly when organizations need clustering for high availability (HA), horizontal scaling for concurrent pipeline reads, or workflow-based approval processes for change governance, Infrahub Enterprise extends the Community core with the features and support needed at larger scale. The Community vs. Enterprise comparison provides a detailed breakdown.
Infrahub’s sizing tiers define resource allocations across deployment profiles, from moderate environments all the way up to tens of thousands of device-class objects. Production deployments today manage datasets well into the hundreds of thousands of managed objects on a single instance, so most organizations approaching Infrahub are well within proven capacity.
How do you architect for scale?
Our default recommendation is a single Infrahub instance with full high availability, including database clustering with automatic leader election, cache failover, and mirrored message queues for bus continuity. A single instance keeps operations simple: one place to manage schema, one resource allocation authority for IPs, prefixes, and identifiers, and one target for monitoring and upgrades.
As previously mentioned, production deployments today manage datasets well into the hundreds of thousands of managed objects on a single instance, so for most organizations this is more than sufficient. Recommended resource baselines for each sizing tier are detailed in the deployment sizing documentation.
That said, some organizations have operational or regulatory reasons to run regionally independent infrastructure. For those cases, Infrahub fully supports a multi-instance deployment model: one instance per region, each with its own HA topology, sharing no state between them. We have customers running this pattern in production today, including one with a formal multi-instance HA deployment managed via Helm.
The multi-instance model adds a second layer of resilience: regional failure isolation. A problem in one region’s Infrahub—whether a maintenance operation, a failed merge, or a service restart—has zero impact on the others. The trade-off is that each region manages its own resource allocation independently, which is usually a natural fit for organizations that already have regional operational boundaries.
What about performance?
Performance isn’t a milestone we hit and move on from—it’s a continuous investment. Our customers operate at scales where every second of pipeline execution and every merge operation matters, and those demands drive our engineering roadmap.
A recent example: We moved core branch-merge logic into the database layer, resulting in roughly a 4x improvement in merge times across datasets ranging from tens of thousands to hundreds of thousands of objects. That kind of deep architectural optimization reflects how we approach performance. It’s not surface-level tuning, but rethinking where work happens to unlock step-change improvements.
On query and Generator performance, we’ve found across deployments that Generator execution, not GraphQL query latency, is typically the build pipeline bottleneck. By working closely with customers to tune how Generators query Infrahub, using targeted field selection instead of eager relationship loading and increasing pagination size, one customer achieved a significant reduction in overall build time, with some individual Generators running up to 10 times faster. These are the same query patterns any downstream build system would use.
This is ongoing work. As our customers grow and their datasets and concurrency requirements increase, we continue to invest in profiling, benchmarking, and optimising Infrahub at every layer of the stack.
What about high avaiability, disaster recovery, and upgrades?
High avaiability (HA), disaster recovery (DR) and upgrades are performance matters that separate a proof of concept from a production deployment, and we take them seriously.
- Resilience: A single HA instance provides component-level resilience out of the box: database clustering, cache failover, and message queue mirroring. For organizations running the multi-instance model, regional failure isolation adds another layer of resilience. In either case, when data-plane agents consume a compiled desired state rather than querying Infrahub directly, an Infrahub outage means only that the build pipeline can’t retrieve updated intent. Hosts continue enforcing their last-known desired state.
- Backup and restore: Database backup is a routine, automated operation that integrates with S3-compatible cloud storage. In large production deployments, compressed backups typically range from single-digit to tens of gigabytes, with substantial compression ratios from raw database size.
- DR targets: Based on production experience with hourly backups, recovery point objective (RPO) is one hour. Recovery time objective (RTO) for restoring a large instance is around one hour, dominated by restoring the task manager database. In architectures where host agents enforce their last-known desired state, the effective data-plane RTO is zero regardless of Infrahub availability.
- Upgrades:The
infrahub upgradecommand handles database migrations (see the Upgrade Guide). For production HA environments, we recommend Kubernetes and Helm as the deployment platform (see installation documentation). It provides the cleanest upgrade path, with the upgrade command running as a Helm job during the release update while Helm manages rolling pod updates. For VM-based HA deployments, we’ve developed formal upgrade procedures that codify the stop/upgrade/restart sequence with safety checks. Organizations running the multi-instance model gain an additional benefit: upgrades naturally follow a canary pattern, upgrading one region, validating, then moving onto the next. In all cases, we recommend a full database backup before every upgrade and validation in a staging environment that mirrors production topology.
Running Infrahub in production: Monitoring, security, and operations
Once the architecture and resilience questions are covered, teams want to know what day-to-day operations look like.
- Monitoring: Infrahub ships with built-in observability. OpenTelemetry distributed tracing is supported natively, with configurable push-based metrics export to any OTLP-compatible backend, including Jaeger, Zipkin, Datadog, and others. Prometheus integration is also available through a pull-based
/metricsendpoint. From our operational experience across deployments, the critical metrics to watch are API request latency, task manager queue depth and database connection pool usage, and disk utilization. - Security: Infrahub supports OAuth2/OIDC SSO and token-based API authentication. The RBAC model provides pre-configured roles (Admin, Standard User, Anonymous User), custom role creation, global permission types including super admin, account management, and schema management, and namespace-scoped object-level permissions with configurable decision types. Infrahub Enterprise adds workflow-based approval processes with configurable approval thresholds and enforced approval gates. All changes are tracked immutably with actor attribution. A production hardening guide is also available.
Growing with Infrahub Enterprise
Infrahub Community and Enterprise editions share the core engine, data model, and APIs. Many teams start with Community, building their schema, integrating data sources, developing Generators, and validating workflows in a lab or early production environment. When the time comes to scale up, moving to Enterprise is seamless since it’s the same platform. Your schema, data, integrations, Generators — everything carries over with no data loss, no migration tooling, and no re-architecture. You pick up exactly where you left off, with Enterprise capabilities enabled on top.
The Enterprise edition extends Infrahub with clustering for high availability, horizontal scaling for concurrent reads from build pipelines, advanced database tuning for larger datasets, workflow-based approval processes for change governance, and SLA-backed support. For organizations operating at scale with production uptime requirements, these are the capabilities that make the architecture viable. A full breakdown of what each edition includes is available in the Community vs. Enterprise comparison.
OpsMill also offers an optional dedicated Solutions Architecture engagement—covering deployment planning, performance tuning, and operational procedures—that can be added to any Enterprise licence. It’s the fastest path from architecture planning to production confidence.
What comes next
We don’t ask teams to take our word on any of these questions. Before production, we’re happy to work with you to run benchmarks using a dataset modeled on your actual schema, so you have concrete numbers for the metrics that matter most to your deployment.
And if it would be helpful, we can facilitate conversations with production customers running at similar scale. There’s no better way to pressure-test production-readiness claims than hearing directly from teams who have already done it.
If any of this resonates, reach out. We’re always happy to engage.
