Set Up Netbox as a Self-Hosted Network Infrastructure Manager

What Netbox Does That a Spreadsheet Cannot

Network documentation has a way of aging badly. A spreadsheet tracking IP allocations looks fine on day one, then quietly drifts from reality as devices get added, subnets get carved up, and nobody remembers to update the master file. Netbox solves this by giving you a self-hosted, database-backed source of truth for your entire infrastructure – covering IP address management (IPAM), device inventory, rack layouts, cable connections, and virtual machines in a single web interface. It was originally built for large data center teams but scales just as well for a home lab administrator who wants to stop guessing which addresses are actually in use.

Running Netbox yourself keeps your network data off third-party platforms and gives you full control over access, backups, and customization. The application is open source, built on Django and PostgreSQL, and designed to run in Docker with minimal friction. This guide walks through a complete self-hosted installation using Docker Compose, including configuration, first-run setup, and a few things worth adjusting before you start adding data.

What You Need Before Starting

The recommended approach for running Netbox without fighting dependency conflicts is Docker. You need Docker Engine installed and Docker Compose available – either as the standalone binary or the plugin version bundled with recent Docker releases. A Linux host works best. The official Netbox Docker repository is maintained separately from the core Netbox project and handles all the container orchestration. You will also need Git to pull that repository down. Beyond that, the requirements are modest: at least 2 GB of RAM and a few gigabytes of disk space for the database over time.

Before pulling anything, decide where you want to store persistent data. PostgreSQL and Redis both write state that needs to survive container restarts, and Netbox itself stores uploaded files. Create a dedicated directory on your host for this project – something like /opt/netbox-docker or a folder inside your home directory – and make sure the user running Docker has write access to it. That directory will anchor everything else.

Pulling and Configuring the Stack

Clone the official Netbox Docker repository with git clone -b release https://github.com/netbox-community/netbox-docker.git and move into that directory. The -b release flag checks out the latest stable release branch rather than the development tip. Inside the directory you will find a docker-compose.yml file and an env folder containing environment variable templates.

Copy the example environment files to live versions: cp env/netbox.env.example env/netbox.env and the same for postgres.env and redis.env. Open each file and set the values that matter. In postgres.env, set POSTGRES_PASSWORD to something strong. In netbox.env, set DB_PASSWORD to the same value, then set SECRET_KEY to a long random string – you can generate one with python3 -c “import secrets; print(secrets.token_urlsafe(50))” if Python is available on your host. Also set ALLOWED_HOSTS to the IP address or hostname you plan to reach Netbox from.

The docker-compose.yml file defines services for Netbox itself, a worker process for background jobs, the PostgreSQL database, Redis for caching, and a separate Redis instance for queuing. You generally do not need to modify this file for a standard install. If you want to expose Netbox on a non-default port, find the ports block under the netbox service and change the host-side port number – for example, 8080:8080 maps port 8080 on your host to the container.

If you plan to put Netbox behind a reverse proxy like Nginx or Caddy, you can remove the ports mapping entirely and instead expose the service only on a Docker network, then route traffic through the proxy. That setup is worth doing if you want HTTPS without managing certificates inside the container. For a home lab running on a trusted local network, the direct port exposure is fine to start.

Starting Netbox and Creating the Admin Account

With configuration in place, bring the stack up with docker compose up -d. Docker will pull all the required images on the first run, which takes a few minutes depending on your connection. Once the containers are running, Netbox runs database migrations automatically on startup. You can watch progress with docker compose logs -f netbox and wait for a line indicating the application is ready.

Create the superuser account by running docker compose exec netbox /opt/netbox/netbox/manage.py createsuperuser. This drops you into an interactive prompt asking for a username, email address, and password. Once that completes, open a browser and navigate to http://your-host-ip:8080. Log in with the credentials you just created and you will land on the Netbox dashboard.

First Steps Inside the Interface

The Netbox interface is organized around a sidebar with major sections: Organization, Devices, IPAM, Virtualization, Circuits, Power, and more. Start by building out the foundational objects before adding anything granular. Under Organization, create at least one Site – this represents a physical location and almost everything else ties to it. If you have a single home lab, one site is enough. Then create a Manufacturer and Device Type entry for at least one piece of hardware so you understand how those objects relate before importing a larger inventory.

For IP address management, navigate to the IPAM section and create your first Prefix. A prefix represents a network block like 192.168.1.0/24. From within a prefix, you can allocate individual IP addresses to specific devices and interfaces, mark addresses as active or reserved, and see at a glance how much of the block is consumed. This is the part of Netbox that replaces the spreadsheet most directly – and where the database-backed approach proves its value, since you can query, filter, and cross-reference in ways a static file never allows.

The Netbox API is available immediately after setup at /api/ and comes with a browsable interface. Every object you can create through the UI can also be created, updated, or deleted via REST API calls. If you are already running other self-hosted tools on your network – for instance, a self-hosted Tailscale control server like Headscale – you can pull Netbox data into automation scripts or push device records in from external sources using the API with a token generated under your user profile. That integration capability is what separates Netbox from a documentation-only tool and makes it worth maintaining long term. Token generation lives under your profile menu in the top-right corner of the interface.