NetBox: a source of truth for your infrastructure

May 9, 2026

At some point in every homelab journey, the spreadsheet stops working.

It starts fine. A sheet for IP addresses. Maybe a second tab for VMs. A third for hardware. You add a new machine, remember to update the sheet, and feel very organized. Then you add three more machines in a weekend of caffeine and BIOS menus, forget to update the sheet, and six months later you’re pinging every address in a subnet trying to remember what lives at .47.

This is the problem NetBox solves. Not because spreadsheets are bad tools — they’re excellent tools — but because infrastructure evolves faster than human memory, and a purpose-built source of truth keeps up where a spreadsheet eventually doesn’t.

What NetBox actually is

NetBox is an open-source web application built specifically for two things: IPAM (IP Address Management) and DCIM (Data Center Infrastructure Management). Those acronyms sound enterprise-y, but the concepts are simple.

IPAM is the practice of tracking IP addresses, subnets, and VLANs in a structured way. Which prefix covers which network segment? Which addresses are assigned, and to what? Which ones are reserved, available, or deprecated? IPAM software answers those questions without requiring you to mentally reconstruct your addressing scheme every time you add a device.

DCIM is tracking the physical and virtual infrastructure itself — servers, switches, network gear, virtual machines, rack layouts, cabling — in a single system. A good DCIM record tells you what hardware exists, where it lives, what software runs on it, and how it connects to everything else.

NetBox handles both. It was originally built by the team at DigitalOcean to manage their own infrastructure, and they open-sourced it. The result is a tool that is clearly designed by people who actually operate networks at scale, rather than by a product team guessing at what engineers need.

The web UI is clean and database-backed. There is a fully featured REST API and a GraphQL endpoint, which means you can query it programmatically, feed it from automation, and integrate it with other tools. It stores everything relationally — a virtual machine knows what host it runs on, what IP addresses it holds, and what prefixes those addresses belong to.

The problem a source of truth solves

The deeper issue with infrastructure documentation isn’t laziness — it’s entropy. Infrastructure changes constantly. A VM gets migrated. A VLAN gets added. An IP address gets recycled. If your documentation lives in a static file or a shared spreadsheet, keeping it in sync with reality requires discipline applied consistently over time, by everyone involved, forever.

That’s a hard human coordination problem, and human coordination problems tend to degrade.

A purpose-built tool like NetBox helps in a few ways. First, it’s designed to model the relationships between things — a VM has IPs, IPs belong to prefixes, prefixes belong to VRFs, devices live in racks — so you capture structure, not just lists. Second, it’s queryable. You can ask “what devices are in this subnet?” or “what IP addresses are unallocated in this prefix?” and get an answer, not a scroll through rows. Third, the API means you can write automation that treats NetBox as the authoritative record — provisioning scripts that pull their IP assignments from NetBox rather than hardcoding them, monitoring configs that build themselves from the inventory.

The phrase commonly used for this is source of truth. One system, one answer, no reconciliation between competing records.

The commercial equivalents

In enterprise environments, this problem is solved by products that cost serious money.

ServiceNow CMDB is the most common. It’s a configuration management database baked into the broader ServiceNow platform, which many large organizations already license for IT service management. The CMDB tracks configuration items (CIs) and their relationships — servers, applications, services, dependencies. It’s powerful and deeply integrated with ServiceNow workflows. It’s also expensive, complex to implement well, and sized for organizations with dedicated administrators.

Device42 is another commercial option, purpose-built for DCIM and IPAM rather than bolted onto a broader platform. It has better physical infrastructure tracking than many competitors and a strong auto-discovery capability. Like ServiceNow, it’s priced for enterprise budgets.

Both products do things NetBox doesn’t — they often include agent-based auto-discovery, deeper ticketing integrations, and extensive reporting. But they also require budgets and operational overhead that make no sense for a homelab, and increasingly don’t make sense for smaller organizations either.

The self-hosted options

If you’ve decided to track your infrastructure properly and don’t want to spend enterprise money, you have a few real options.

A spreadsheet is always option zero. It works better than nothing, it’s universally accessible, and if your lab is small and stable enough, it may genuinely be sufficient. The failure mode is drift — the spreadsheet stops reflecting reality, and you stop trusting it, and then it’s worse than nothing because you’re not sure whether to believe it.

Nautobot is worth knowing about. It started as a fork of NetBox, maintained by the Network to Code team, and has evolved into something with a heavier focus on automation and extensibility. If you’re building network automation workflows and want tighter integration between your source of truth and your automation tooling, Nautobot is worth evaluating. For a homelab that wants documentation more than automation, it’s probably more than you need.

NetBox hits the right spot for most homelab use cases. It’s mature — the project has been around since 2016 — actively maintained, well-documented, and deployed widely enough that most questions have been answered somewhere. The data model is opinionated in useful ways. It runs comfortably on modest hardware. And critically, there’s a Docker Compose deployment path that makes getting it up and running a manageable afternoon project rather than a multi-day infrastructure commitment.

How it fits a homelab in practice

The stack is container-based: the NetBox application itself, a background worker for async jobs, a housekeeping container for periodic cleanup, a PostgreSQL database, and a pair of Redis instances — one for the task queue, one as a volatile cache.

⚠️ Unverified: Resource requirements vary by deployment size, but the Docker Compose setup is commonly documented as running well on 4 vCPUs and 8GB RAM for homelab-scale workloads.

In practice, NetBox earns its keep through consistency more than cleverness. You build the habit of adding a device to NetBox when you provision it. You assign IPs from NetBox before you configure them on the device. When you want to know what’s running where, you check NetBox first. Over time, the system accumulates a faithful map of your infrastructure that’s genuinely useful when something breaks, when you’re planning an upgrade, or when you’ve simply forgotten what you set up three months ago.

The REST API is particularly valuable once you’ve built the habit. Terraform providers, Ansible dynamic inventory plugins, and custom scripts can all pull data from NetBox — which means your automation stops relying on hardcoded values scattered across playbooks and starts asking the source of truth. That’s the direction infrastructure management is supposed to go.

For a homelab running a mix of physical hardware, virtual machines across one or more hypervisor nodes, and a meaningful number of network segments, NetBox covers the full picture. Racks and physical devices. VMs mapped to their hosts. IP addresses tied to specific interfaces on specific machines. Prefixes organized by purpose. VLANs with descriptions that explain why they exist.

One pattern that works well: populate NetBox before you need it, not after something goes wrong. The value compounds with completeness. A half-populated CMDB is worse than no CMDB because it gives you false confidence — you look up a device, don’t find it, and you’re not sure whether it doesn’t exist or just hasn’t been documented yet. If you commit to keeping it current, it becomes genuinely reliable. If you don’t, it becomes a historical curiosity that you stop trusting.

Who should bother

NetBox is worth setting up if your homelab has grown to the point where you genuinely lose track of things. If you’ve ever:

• Pinged a whole subnet to find a device you couldn’t remember the IP for
• Found a VM you forgot you created
• Accidentally double-assigned an IP address
• Needed to explain your network layout to someone else and had no good way to do it
• Wondered whether a particular IP address is free before assigning it to something new

…then a source of truth will pay for itself in reduced frustration.

If your homelab is a few devices and a flat network and you know every address from memory, a spreadsheet is probably fine and NetBox would be overhead without proportional benefit. There’s no virtue in running software you don’t need. The threshold is roughly: if you’re managing multiple network segments, running more than a handful of virtual machines, or planning to grow significantly, the structure NetBox provides starts making more sense than it costs.

The other consideration is maintenance discipline. NetBox only works if you actually keep it updated. A stale CMDB is almost actively harmful — it tells you something authoritative and confidently wrong. If you’ll update it consistently, it’s an excellent investment. If your honest assessment is that you won’t, the spreadsheet will drift too but at least you know not to trust it.

One way to build the habit: treat NetBox as a provisioning prerequisite, not an afterthought. Before you spin up a new VM or connect a new device, open NetBox, claim an IP from the right prefix, and create the record. By the time the machine is running, the documentation is already done. It takes thirty seconds, and it means the database stays current without requiring a separate documentation pass that you’ll always find reasons to defer.

The honest case for it

The real reason to run a source of truth in a homelab isn’t organizational neatness, even if that’s a real side effect. It’s that infrastructure — even homelab infrastructure — accumulates complexity faster than memory handles it. The lab you have in a year will be meaningfully different from the lab you have today, and future-you will be grateful that past-you left a coherent record.

NetBox is a professional-grade tool that happens to be open-source, well-supported, and entirely reasonable to run at home. The concepts it embodies — structured IP management, relational infrastructure modeling, a single queryable record of what exists and where — are the same concepts that enterprise organizations pay substantial money to implement. Running it yourself means you get the practice, the tooling, and the habits without the invoice.

That’s a pretty good deal.

← all posts