NetBox Setup for CMDB and Infrastructure Management

We have repeatedly encountered situations where a spreadsheet with IP addresses that "everyone knows" stops working at some point. Someone assigns 10.20.30.50 to a new server, unaware that the address is already taken. Someone forgets to update the document after hardware relocation. Terraform tries to create a resource with an already-used IP and fails. NetBox solves this: it is the single source of truth for IP addressing, equipment inventory, cable documentation, and relationships between network objects. Over 5 years, we have deployed NetBox on more than 20 projects—from small startups to enterprises with thousands of devices.

Why NetBox beats spreadsheets

Spreadsheets do not ensure referential integrity: one engineer changes an IP, another misses the update. NetBox uses a relational model: Prefix → IP Address → Interface → Device → Site. Any change is instantly visible to everyone, and the API eliminates manual errors. Compare: manual IP conflict checking in a spreadsheet takes 10–30 minutes; NetBox does it in seconds.

How we set up NetBox turnkey

We take care of the entire cycle: from deployment to team training.

Deployment and initial setup

NetBox is installed via Docker or directly on Linux. The Docker option is easier to maintain:

# docker-compose.yml (fragment)
services:
  netbox:
    image: netboxcommunity/netbox:v3.7
    environment:
      - DB_HOST=postgres
      - DB_NAME=netbox
      - DB_USER=netbox
      - DB_PASSWORD=${DB_PASSWORD}
      - SECRET_KEY=${SECRET_KEY}
      - ALLOWED_HOSTS=netbox.internal
    volumes:
      - ./config/configuration.py:/etc/netbox/config/configuration.py
    depends_on:
      - postgres
      - redis

In configuration.py, it is important to set ALLOWED_HOSTS, configure LDAP/SSO if integration with Active Directory is needed, and define REMOTE_AUTH_BACKEND for SSO via SAML or OAuth2. Without this, users are created manually—not viable in production.

Data structure: from physical to logical

NetBox models infrastructure in layers. Physical level: Sites → Racks → Devices. Logical level: IP Address → Prefix → VRF → RIR. The connection: devices have Interfaces, interfaces have IP addresses from a specific Prefix.

For new infrastructure, the order is: create a Site, add a Rack (with rack unit height), register Device Types (can be imported from the official library netbox-community/devicetype-library). Device Types are templates that specify which interfaces, power supplies, and slots a particular server model has. When creating a Device from a type, all components are created automatically.

For IP addressing: create an RIR (e.g., RFC 1918 for private space), add Aggregates (e.g., 10.0.0.0/8), break into Prefixes by purpose—a /24 for each VLAN. When assigning an address via UI or API, NetBox automatically selects the next available one in the specified Prefix.

API as the main integration tool

The value of NetBox lies not in the pretty UI but in the REST API and Python SDK. Example via pynetbox:

import pynetbox
nb = pynetbox.api('https://netbox.internal', token='abc123...')

# Find next free IP in prefix
prefix = nb.ipam.prefixes.get(prefix='10.20.30.0/24')
next_ip = prefix.available_ips.create()
print(next_ip)
# {'address': '10.20.30.12/24', 'family': 4}

# Register a new server
device = nb.dcim.devices.create(
    name='node-07',
    device_type=nb.dcim.device_types.get(model='PowerEdge R640').id,
    site=nb.dcim.sites.get(slug='dc-main').id,
    device_role=nb.dcim.device_roles.get(slug='server').id,
    status='active'
)

This code is called from an Ansible playbook during server provisioning—IP is assigned automatically, the host is registered in CMDB, and then Terraform or other tools read the infrastructure from NetBox as the source of truth.

Dynamic Ansible inventory via NetBox:

# inventory/netbox.yml
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.internal
token: "{{ lookup('env', 'NETBOX_TOKEN') }}"
group_by:
  - device_roles
  - sites
  - tags

ansible-inventory -i inventory/netbox.yml --list returns all devices with status active, grouped by roles and sites.

Custom fields and webhooks

For specific attributes (e.g., purchase ticket number, responsible engineer, warranty expiration date), Custom Fields are used—added via UI or API without altering the database schema.

Webhooks allow reacting to events: when a new IP address is created, a POST request can be sent to Ansible AWX to trigger a playbook, or to JIRA to create a task. Configured via NetBox → Customization → Webhooks:

{ "name": "New IP → AWX",
  "type_create": true,
  "object_type": "ipam.ipaddress",
  "url": "https://awx.internal/api/v2/job_templates/42/launch/",
  "http_method": "POST",
  "http_content_type": "application/json",
  "secret": "webhook-secret"
}

What's included

• Basic deployment: Docker infrastructure, LDAP/SSO, backup configuration.
• Data import: migration of existing IP addressing, devices, connections (scripts or manual input).
• Integrations: Ansible (dynamic inventory), Terraform (data sources), webhooks for CI/CD.
• Documentation: data model description, team instructions, runbook for common operations.
• Training: 2–3 sessions for administrators and developers.
• Support: 1 month of post-release support.

Timeline and pricing

Basic deployment with Docker, LDAP setup, import of Device Types—2–3 business days. Populating existing infrastructure (IP addressing, devices, racks) depends on volume: 50–100 devices manually or via import script—another 2–5 days. Integration with Ansible, Terraform, webhook setup—a separate block from 1 to 3 days depending on the number of integrations. Pricing is calculated individually after an audit. We will assess your project—contact us.