Configuration drift is one of those infrastructure problems that is easy to describe and genuinely hard to eliminate. You deploy a network device with a specific IP assignment, VLAN membership, and interface configuration. Six months later, a change is made manually during an incident. The documentation is not updated. The Terraform state no longer reflects reality. The inventory file the team uses for Ansible has a different version of the device’s role.
None of this happens because engineers are careless. It happens because configuration intent is scattered across multiple systems — and when those systems fall out of sync, there is no single place to go and find out what the environment is actually supposed to look like.
The scattered intent problem
Most infrastructure environments have configuration intent in at least four places: the provisioning code, the state files, the inventory, and the documentation. In the best case, they all agree. In practice, they drift.
The provisioning code reflects what someone intended when they last ran it. The state file reflects what was actually provisioned at that point. The inventory might be manually maintained and weeks out of date. The documentation is aspirational.
When you need to make a change — add a new host, modify a VLAN, update a routing configuration — you have to reconcile four sources of partial truth before you can be confident about what you are changing. That reconciliation takes time, introduces opportunities for error, and produces exactly one result: an updated version of the same fragmented system.
A source-of-truth model is a different approach. One system holds the authoritative state of intent. Everything else derives from it.
NetBox as the authority
NetBox is a network infrastructure management tool designed to model IP address space, device inventory, virtual machines, network topology, VLANs, services, and their relationships. It is a documentation platform with an API, which makes it useful as a data source for automation rather than just a wiki.
The shift in thinking is treating NetBox not as a record of what has been provisioned, but as the authority for what should be provisioned. When a new host needs an IP address, the IP is allocated in NetBox first. When a device is added to a VLAN, the membership is defined in NetBox before any configuration is applied. When a service endpoint changes, NetBox is updated before the automation runs.
# Query NetBox for all hosts in the platform role, lab environment
curl -s "https://netbox.internal/api/dcim/devices/?role=platform&tag=lab" \
-H "Authorization: Token $NETBOX_TOKEN" | jq '.results[] | {name, primary_ip}'
# Output feeds directly into inventory generation for Ansible
hyops run platform/onprem/inventory-sync --source netbox --env labWhen NetBox is the authoritative source, the provisioning code is not the source of truth — it is an implementation of the truth. Terraform and Ansible consume NetBox data to produce infrastructure that matches the declared intent. If the state file drifts from NetBox, that is detectable and correctable. The authority is clear.
What this changes operationally
The most immediate change is in the operational questions you can answer.
“What IP is assigned to this host?” has one answer: NetBox. Not the Terraform state, not the DNS entry, not the inventory file that someone maintains by hand. NetBox.
“What services does this device provide?” One answer.
“Which hosts are in the lab environment?” One query, one result, consistent across provisioning tools.
This sounds obvious when written out, but I’ve worked in environments where none of those questions had a clean answer. The IP address was in the Terraform state, a different address was in the inventory, and the monitoring had picked up a third one from a DHCP lease. All three were different. Nobody could confidently say which one was correct.
When a single system is authoritative, that kind of drift is detectable rather than invisible. You can compare the provisioned state against the NetBox record and surface discrepancies. You can build validation probes that check whether the live infrastructure matches the declared intent.
The discipline required
A source-of-truth model only works if the discipline to maintain it holds. NetBox is only authoritative if engineers consistently update it before making infrastructure changes — not after, not sometimes, but as the first step.
This is harder than it sounds. Under time pressure, updating NetBox feels like overhead. The change needs to happen now; the documentation can wait. And once “it can wait” becomes the norm, the source of truth stops being true.
The operational model needs to make NetBox updates part of the change process, not a separate documentation task. In practice this means automation that reads from NetBox before it runs — so running the automation with a stale or incomplete NetBox record produces an obvious error rather than quietly proceeding with wrong data.
HybridOps integrates NetBox as a first-class data source in this way: modules that provision hosts or network resources query NetBox for the authoritative state before execution. If the NetBox record does not match what the module expects to find, the preflight check fails. That friction is deliberate — it enforces the discipline that keeps the source of truth credible.
Where this fits in a broader automation model
NetBox-driven automation is most valuable in environments where infrastructure changes frequently enough that manual documentation cannot keep up, but carefully enough that every change should be intentional and traceable.
Hybrid environments with on-prem networking, cloud landing zones, and edge capacity are a good fit. The IP space spans multiple environments. The device inventory is heterogeneous. The service topology changes as modules are deployed and retired. Keeping all of that coherent without a single authoritative source is possible — it just requires an amount of manual effort that grows with the environment.
The automation model that derives from NetBox does not eliminate that effort. It moves it upstream, to the point where intent is declared, and makes everything downstream more reliable as a result.
Infrastructure becomes predictable when intent is centralised. That is the argument for source-of-truth automation, and it holds regardless of which tool you use to implement it.