Most automation projects fail on one banal thing: nobody knows exactly what is actually running in the network and server room. IP addresses in Excel, wiring in one admin's head, two-year-old docs. Without a source of truth, automation is built on sand. NetBox changes that.
What NetBox is
NetBox is an open-source tool for IPAM (IP address management) and DCIM (data center infrastructure management). Simply: a single place recording what you have, where it is, how it's wired and what addresses it uses — from rack and cabling and VLAN to virtual machines and cloud.
Automation is only as good as the data it runs on. NetBox is that data source.
Why it's the foundation of automation
When Ansible or Terraform deploy a change, they need to know: which server, which VLAN, which IP. If that data comes from Excel or memory, automation is fragile. NetBox as a single source of truth fixes this — playbooks read truth from an API, not assumptions.
- Network-as-code — network config is generated from NetBox, not by hand.
- Provisioning — a new server gets its IP and VLAN automatically by rules.
- Audit and compliance — you always know what you have. Crucial for NIS2 and internal audit.
Reality check
- NetBox is only as good as you populate it. Initial population with the real state is work — but one-off and essential.
- It's not monitoring. NetBox says what should be. What actually runs is watched by Zabbix or Logmanager. Together they form the full picture.
- Integration pays off. The real power is in wiring it to Ansible, Terraform and CMDB.
How we deploy it
We start with discovery — scanning the real state and importing it into NetBox. Then we wire the automation pipeline (Red Hat Ansible Automation Platform) so NetBox is both source and target.
# NetBox as source of truth — config is generated from data, not by hand
- name: Generate switch configs straight from NetBox
hosts: localhost
connection: local
tasks:
- name: Load active core switches from NetBox
ansible.builtin.set_fact:
netbox_devices: "{{ query('netbox.netbox.nb_lookup', 'devices',
api_endpoint='https://netbox.internal',
api_filter='status=active role=core-switch') }}"
- name: Render config from template + data
ansible.builtin.template:
src: switch.cfg.j2 # one template, data from NetBox
dest: "configs/{{ item.value.name }}.cfg"
loop: "{{ netbox_devices }}"
- name: Assert every device has an assigned IP
ansible.builtin.assert:
that: item.value.primary_ip4 is not none # missing IP = an inventory error, not a production one
loop: "{{ netbox_devices }}"Key point: NetBox is both source and target — automation reads from it and writes the real state back. No Excel. Lookup plugin: NetBox docs.
Provisioning a new rack (40 devices) took 3 days of manually chasing IPs and VLANs in spreadsheets. With NetBox as source of truth: 4 hours, zero IP conflicts. Illustrative figures — verify before publishing.
Frequently asked questions
How do we get the real state into NetBox when our Excel is a mess?
Discovery. We scan the real network and servers, import the result into NetBox and compare with Excel — the differences are usually surprising. From then on NetBox is the source of truth and Excel goes to the archive.
What if NetBox and reality diverge?
That's why we use NetBox as both source and target — automation regularly verifies that reality matches NetBox and reports drift. A device not in NetBox is either an error or an unauthorized change.
Does it work for virtual and cloud infrastructure?
Yes. NetBox models physical and virtual devices, IP space, VLANs and connections across on-prem and cloud. It's vendor-neutral, so it doesn't tie you to one manufacturer.
How does NetBox fit the rest of the automation?
It's the foundation. F5 config, Zabbix monitoring and server provisioning all read their target state from NetBox. One source, many consumers.
Is your network state in Excel?
Book a 20-minute call — we'll show you how to turn the chaos into one source of truth and what it means for your automation. No sales pitch.
Book a 20-min call →