An Introduction to Infrahub Sync (With FAQs)

Your network devices are tracked in NetBox, circuit information is in another system. ServiceNow has your assets. IP Fabric knows what's actually running. Somewhere in there, someone has a spreadsheet that's supposed to tie it all together.

Sound familiar?

If it does, it's because that's how most infrastructure teams work: with data scattered across a bunch of different platforms, tools, and data stores. Each system holds part of the story but none of them talk to each other. So when you need to configure a device, generate a report, or troubleshoot an outage, you're stuck manually aggregating data from multiple sources.

Data fragmentation bogs down every project with time-consuming data detective work. Even worse, data silos also break automation, create security gaps, and leave you constantly questioning which system actually has the right information.

Infrahub Sync tackles this problem head-on. It's an automated data synchronization tool that unifies infrastructure data across the organization, without forcing you to rip and replace the tools your teams already rely on.

Infrahub Sync in a nutshell

Infrahub Sync is a Python CLI tool that automatically synchronizes data between infrastructure platforms like NetBox, Nautobot, IP Fabric, Peering Manager, and Infrahub.

Instead of writing custom scripts or maintaining manual update processes, you define your data flows in a simple YAML configuration file. Infrahub Sync handles the rest, using intelligent diff calculation to move only what's changed between systems.

The tool solves a specific problem: keeping infrastructure data consistent across the multiple systems you need to run your network. It doesn't try to replace your existing tools. It makes them work together.

Built on the open-source DiffSync library, Infrahub Sync provides idempotent synchronization. That means you can run it repeatedly without worrying about duplicate data or unintended changes.

It tracks data lineage so you always know where information originated. And it integrates with Infrahub's branching model, letting you test synchronizations before applying them to production.

Why data silos break infrastructure automation

When data lives in disconnected systems, three things suffer: speed, reliability, and trust.

As an example, when new devices are deployed, the network ops team needs those devices added to their systems for monitoring and logging. But if the handover process between teams relies on manual updates, devices get missed. Missed devices aren't monitored. Security scans don't run and access policies aren't applied.

Configuration generation is another example where scattered data can hurt. You're pulling device models from one system, IP addressing from another, and service information from a third. If any of that data is stale or missing, your automation fails. Or worse, it succeeds with the wrong configuration.

Business intelligence becomes nearly impossible with siloed data. You're often stuck aggregating data manually when you need to answer basic questions about circuit costs, device utilization, or service deployments. The people who need that information most—finance, leadership, security teams—can't get it without help from someone who knows which system(s) to check.

The traditional workarounds don't scale. You can document sync processes in Word files or runbooks that engineers are supposed to follow. But people are people: They skip steps, they forget steps, or they ignore the docs completely. And since no one tracks which system should be authoritative for each piece of data, even if the syncs are done, the conflicts pile up.

Custom scripts fill some gaps but they can be brittle. When a vendor changes its API or your schema evolves, those scripts tend to break. Now you're maintaining integration code instead of building automation.

How Infrahub Sync works

Infrahub Sync replaces manual processes and custom scripts with a configuration-driven approach.

You define three things in a YAML file: your source system, your destination system, and how fields map between them. The tool generates the underlying Python adapters automatically, so you don't need to write integration code.

The workflow breaks into three commands:

• Generate creates DiffSync adapters and models based on your configuration. You run this whenever you update your config file.
• Diff compares the source and destination, showing you exactly what will change before you apply anything. This preview step is critical when you're testing a new sync or troubleshooting data inconsistencies.
• Sync applies the changes, moving only what's different between the two systems. Because it's idempotent, running the same sync twice won't create duplicates or cause drift.

Field mappings can be one-to-one (e.g., device name to device name) or transformed using Jinja2 expressions. This ability to transform data during a sync solves the headache of formats that don't align perfectly between systems. For example, you might need to lowercase hostnames, combine multiple fields into one, or convert a float to an integer to make things congruent.

Using filters, you control what data gets synchronized. You can, for example, sync only network devices (excluding PDUs and patch panels), only devices in specific regions, or only objects that meet particular criteria. This keeps your destination system clean and focused on the data you actually need.

Relationships between objects are preserved through the sync process. When you synchronize devices, their connections to sites, racks, device types, and tags come along. Infrahub Sync respects the order you define, ensuring parent objects exist before children that reference them.

Data lineage (aka metadata) captures where each piece of information originated. When you're looking at a device in Infrahub that was synced from NetBox, you can see that source explicitly. Metadata is helpful when troubleshooting discrepancies or determining which system should be authoritative.

Data syncs through Infrahub Sync are branch-aware. That means you can review and test syncs in Infrahub branches before moving any data to production. This adds a safety layer that manual syncs and direct API updates can't provide.

Supported platforms and adapters

Infrahub Sync currently supports synchronization with NetBox, Nautobot, IP Fabric, Peering Manager, LibreNMS, Observium, Slurp'it, Prometheus, Cisco ACI, and generic REST APIs. You can also build local adapters for systems that don't have built-in support.

The direction of the sync depends on the adapter. Some support bidirectional flows (you can sync to and from Infrahub), while others are currently one-way. NetBox to Infrahub is one-way, for example. Peering Manager supports bidirectional synchronization.

The most common patterns we see:

• NetBox or Nautobot to Infrahub for brownfield migrations. Teams bring existing device, circuit, and IPAM data into Infrahub while keeping their current tools operational during the transition.
• Slurp'it or IP Fabric to Infrahub for network discovery. These tools crawl your live infrastructure and generate device inventories. Syncing that discovered data into Infrahub gives you a starting point for modeling your network.
• Infrahub to Peering Manager for BGP automation. You define peering policies and relationships in Infrahub, then push that intent to Peering Manager for configuration generation.
• Multiple sources to Infrahub for unified data. You might pull device inventory from one tool, circuit data from another, and business service information from a third. Infrahub becomes the aggregation point where all that context comes together.

Common use cases for Infrahub Sync

• Brownfield data migration: You've decided to adopt Infrahub, but you already have years of device, rack, and circuit data in NetBox. Infrahub Sync lets you bring that data over without manual exports and imports. You maintain your NetBox instance while gradually expanding your data model in Infrahub. As you build out new schemas for services or business logic, the existing infrastructure data is already there, properly synchronized.
• Mergers and acquisitions: When companies merge, you're typically dealing with multiple network inventories built on different tools and methodologies. Infrahub Sync lets you aggregate these disparate inventories into a single view without forcing immediate migration away from existing tools. You can reconcile conflicting data, identify gaps, and gradually build a unified source of truth while maintaining operational continuity during the transition.
• Multi-system aggregation: Your device inventory lives in a CMDB. IP addressing is managed in an IPAM tool. Monitoring data comes from IP Fabric or LibreNMS. Each system serves a purpose, but automation needs data from all of them. Infrahub Sync pulls the relevant pieces into Infrahub, creating a unified view without forcing you to migrate away from existing tools. You maintain clear data lineage so everyone knows which system owns which data.
• Real-time operational state: You're managing configuration intent in Infrahub but operational state lives in your monitoring and observability tools. Infrahub Sync can bring device status, interface states, or performance metrics into Infrahub periodically. Your automation can then make decisions based on current network conditions, not just intended state. This matters for workflows like automated remediation or capacity planning.
• Service provider automation: If you're running an ISP or managing infrastructure as a service, customer information lives in business systems while network data lives in technical tools. Infrahub Sync can bridge that gap, pulling customer records or service definitions into Infrahub where they can be connected to peering sessions, circuits, and device configurations. This creates the context you need for accurate service provisioning and billing.

Infrahub Sync FAQs

Ready to eliminate your data silos?

• Dig into the Infrahub Sync documentation, which includes installation guides and configuration examples.
• Watch a technical hands-on walkthrough that demonstrates a data sync from NetBox to infrahub.
• Book time with the OpsMill team to discuss your current data states, and how Infrahub can get you out of data silos into a unified data engine.