NetBox as a DCIM Starter Kit for SMBs

Anyone maintaining network documentation in a mid-sized company knows the picture: an Excel wallpaper with IP addresses, a Confluence page with rack sketches, a Visio file from the year the last network admin left, plus a handful of screenshots from the switch GUI. It works — until the first outage, an office move, or an auditor asking for a defensible asset list. Beyond that point, a real DCIM and IPAM tool starts to pay for itself, and NetBox has been the pragmatic standard for years.

NetBox 4.3 is open source, written in Python/Django, and covers exactly the three areas that make Excel especially painful: rack and site management (DCIM), IP address management (IPAM) and modelling connections between devices, providers and virtual resources. We have been deploying NetBox at customers with 10 to 300 endpoints for several years, and this article shows what a realistic starter kit looks like — from an empty server to the first Ansible integration.

When NetBox is the right entry point

NetBox is not a tool for everything. It is a “source of truth” for the target state of your infrastructure, not a monitoring system, not a ticketing tool, and not a full ITIL-style CMDB. That is exactly why it works so well in the mid-market: it does not force any process framework on you, it just provides a clean data model and an API for other tools to plug into.

The entry point typically becomes worthwhile in one of the following situations:

• You operate more than one rack or more than one site and IP planning has already collided once.
• You automate configurations with Ansible, Terraform or Nornir and need a structured data source.
• Auditors, TISAX, or NIS2 exposure require a defensible asset inventory.
• Your team is growing and “where is that printer on the second floor plugged in” only lives in one person’s head.

If none of that applies, a well-kept wiki is enough. From the first point onwards, the half-day of setup almost always pays back.

The data model in four layers

Before you spin up the first VM it helps to understand the NetBox data model. It is strictly hierarchical, and that is precisely where its value comes from: you cannot create an “IP address without a prefix” or a “rack without a site”. Long term, this discipline prevents exactly the data landfill you know from Excel.

Layer	Objects	Typical SMB content
Location	Region, Site, Location	HQ Neuburg, Munich branch, ground-floor server room
Physical	Rack, Device, Module, Cable	42U rack, switch, server, patch cable
Logical	VLAN, VRF, Prefix, IP address	VLAN 20 Client, 10.20.0.0/16, 10.20.1.5/24
Virtualisation	Cluster, VM, VMinterface	Proxmox cluster, VM fileserver01, eth0

There is also a “Circuits” layer for WAN connections (telco line, leased line, SIP trunk) and “Tenancy” for multi-tenant separation, if you need to represent several companies or customers. For the initial rollout, the first four layers are enough.

Setup in four hours

We install NetBox in almost every customer project as a Docker Compose stack on a small VM — typically two vCPUs, 4 GB RAM and 40 GB storage. That comfortably handles four-digit object counts. The official netbox-docker stack is well maintained, and we configure it as follows:

# docker-compose.override.yml
services:
  netbox:
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      SUPERUSER_NAME: admin
      SUPERUSER_EMAIL: it@example.com
      ALLOWED_HOSTS: "netbox.intern.example.com"
      TIME_ZONE: "Europe/Berlin"
      REMOTE_AUTH_ENABLED: "true"
      REMOTE_AUTH_HEADER: "HTTP_X_REMOTE_USER"

In front of the NetBox VM we place an Nginx reverse proxy with LDAP or OIDC authentication (for Entra ID customers typically via oauth2-proxy), so login is tied to the existing identity. A regular PostgreSQL backup wired into the existing backup strategy rounds off the base install.

The real time sink is not the installation but the initial data load. A realistic four-hour plan looks like this:

• 30 minutes: bring up the Docker stack, configure the reverse proxy and test login.
• 30 minutes: define custom fields (asset tag, purchase date, cost centre).
• 60 minutes: create sites, racks and rack roles.
• 90 minutes: import device types from the community library and enter existing hardware.
• 30 minutes: capture IP prefixes, VLANs and the most important circuits.

The device-type library on GitHub ships ready-made YAML definitions for the common models from Dell, HPE, Cisco, MikroTik, Ubiquiti and others — that saves roughly 15 minutes of grooming per device class.

IPAM: from Excel chaos to a clean hierarchy

The fastest “aha” moment usually happens in the IPAM module. NetBox strictly models IP addresses as aggregates, prefixes and addresses, with optional VRF assignment. A typical setup for a mid-sized company with two sites looks like this:

Aggregate: 10.0.0.0/8 (RFC1918)
├── Prefix: 10.10.0.0/16    (HQ site)
│   ├── Prefix: 10.10.10.0/24  VLAN 10 Management
│   ├── Prefix: 10.10.20.0/24  VLAN 20 Client
│   └── Prefix: 10.10.30.0/24  VLAN 30 Server
└── Prefix: 10.20.0.0/16    (Branch site)
    ├── Prefix: 10.20.10.0/24  VLAN 10 Management
    └── Prefix: 10.20.20.0/24  VLAN 20 Client

Every prefix has a status (active, reserved, deprecated), a utilisation display and a link to the assigned IP addresses. The “Available IPs” view shows in seconds which address is next free — without anyone updating an Excel row. Combined with clean firewall documentation on top of OPNsense, the classic “did we already assign 10.10.30.42” discussions disappear completely.

Integration with Ansible and Prometheus

The real leverage kicks in the moment NetBox stops being just documentation and becomes the source for other systems. In our experience, two integrations deliver the fastest return:

Ansible dynamic inventory via the netbox.netbox.nb_inventory collection: you define once which NetBox filters (e.g. device_roles=proxmox-host) produce which Ansible groups, and Ansible pulls the current device list from the API on every playbook run. Newly added servers show up in the next configuration run automatically — no manually maintained hosts.ini.

# inventory.yml
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.intern.example.com
token: !vault | ...
group_by:
  - device_roles
  - sites
  - tags

Prometheus service discovery via the netbox-agent exporter or directly via http_sd_config: Prometheus queries NetBox for all devices tagged monitoring and generates the scrape targets from that. A freshly racked switch is monitored the moment it carries the right tag in NetBox. For our Linux customers with mixed bare-metal and Proxmox environments, this is the most convenient way to avoid monitoring blind spots.

When NetBox reaches its limits

NetBox is deliberately slim. It is not a full-blown CMDB and it replaces neither an ITSM tool nor software asset management. We recommend switching or complementing it as soon as:

• You want to model changes with approval workflows (Change Advisory Board, formal approvals). NetBox has “change logs” but no real workflow engine.
• You need to track software licences, maintenance contracts and financial depreciation — that belongs in an ITSM or ERP system.
• You want to run proper ticketing processes (incident, problem, request). Zammad or OTRS fit better here and can be coupled to NetBox via API.
• You need compliance evidence for NIS2 or ISO 27001 at the asset level beyond what custom fields can express.

In these cases NetBox often stays in place as the “data layer” and is connected to the higher-level system via webhooks or API — a pattern we regularly run in TrueNAS-heavy storage environments with parallel NAS documentation and in larger Proxmox environments with CI/CD integration.

Conclusion

NetBox is not a framework that requires weeks of process design — it is a pragmatic tool that stands up in a morning and creates order from day one. The biggest mistake on entry is trying to model every conceivable custom field up front. Start with the standard model, fill it cleanly, and only add fields once they are genuinely missing more than once. The second typical mistake is skipping the API integration: running NetBox as pretty documentation only wastes 80 percent of its value.

DATAZONE helps you build clean network and asset documentation — from the initial NetBox setup and the migration of your Excel inventories to the integration with Ansible, Prometheus and your existing Proxmox or TrueNAS environments. Get in touch if you want to end the Excel sprawl.