Picture a two-person IT team that has just lost a Saturday to an address conflict and decided the spreadsheet has to go. They shortlist the two open-source names everyone mentions, stand up both in a test VM, and discover they are not really the same kind of product. phpIPAM feels like an address register that also checks the network. NetBox feels like a model of the whole infrastructure in which IP addresses are one chapter. Both are free to self-host. The choice comes down to what you want the record to do when it disagrees with reality.
At a glance
| phpIPAM | NetBox | |
|---|---|---|
| Licence | GPLv3, self-hosted | Apache 2.0 (Community); paid NetBox Cloud and Enterprise from NetBox Labs |
| Stack | PHP + MySQL/MariaDB on a web server | Python/Django + PostgreSQL + Redis |
| Scope | IP addresses, subnets, VLANs, VRFs, plus basic devices/racks | IPAM plus DCIM: sites, racks, devices, interfaces, cables, circuits, virtualization |
| Built-in network scanning | Yes: ping/fping status checks and host discovery via cron scripts | No: NetBox does not talk to network nodes; discovery is a separate product or your own scripts |
| Import | XLS/CSV per subnet | CSV/YAML/JSON bulk import in the UI, plus API |
| API | REST API | REST and GraphQL APIs; available-IP and available-prefix endpoints |
| Overlapping space | VRFs | VRFs, each optionally enforcing unique addresses |
| Typical learning curve | Short; recognisable within an afternoon | Longer; the data model rewards planning |
| Best fit | SMB and mid-size teams wanting an IP register that notices drift | Teams heading toward automation and a full infrastructure source of truth |
The real difference: who reconciles
On this site the main test is how well a tool keeps the recorded plan and the live network in agreement. The two products answer that very differently.
phpIPAM reconciles for you. Per subnet you can turn on status checks and host discovery, then schedule the bundled pingCheck.php and discoveryCheck.php scripts from cron. The first updates when each recorded address was last seen; the second reports live hosts that are not in the record. For a team whose main pain is undocumented statics and stale rows, that loop is the whole point, and it works on day one with no code.
NetBox expects to be told. Its own documentation is explicit that it does not interact with network devices directly; it publishes data for automation, monitoring and assurance tools to consume. Reality gets in through imports, the API, or an add-on: NetBox Labs sells NetBox Discovery and NetBox Assurance, and the community has plugins and scripts. The upside is a cleaner model of intent. The downside is that “what answers on the wire” isn’t compared with the record unless you build or buy that step.
Data model and scope
phpIPAM is organized around sections, subnets and addresses, with VLANs, VRFs, NAT entries, devices and racks alongside. It is deliberately IP-centric, and that keeps the interface quick for helpdesk staff who only need to find or claim an address.
NetBox starts from sites, devices and interfaces. An IP address in NetBox can be assigned to a specific interface on a specific device, and prefixes nest automatically under aggregates. VLANs can be grouped so that IDs stay unique per site or scope. This makes questions like “which switch port is 10.60.2.140 on?” answerable from the record, provided someone keeps interfaces and cables documented. If nobody will, that extra structure becomes empty fields.
Automation and APIs
Both have REST APIs, but NetBox is built API-first. Asking for the next free address in a prefix is one call:
curl -s -H "Authorization: Bearer $NETBOX_TOKEN" \
https://netbox.example.net/api/ipam/prefixes/42/available-ips/?limit=1A POST to the same endpoint allocates it. Current releases use v2 tokens with the Bearer scheme; the older Token scheme is deprecated and slated for removal in 5.0. Ansible, Terraform and many internal tools already speak NetBox, which is why teams heading toward config generation tend to land there.
phpIPAM’s API covers sections, subnets, addresses and first-free-address lookups too, and is perfectly usable for provisioning scripts. It is simply not the centre of the product the way it is in NetBox.
Running it
phpIPAM runs on a standard LAMP-style host; the 1.8.x branch supports PHP 7.2 through 8.5 with MySQL or MariaDB. Upgrades are mostly “replace files, run the database migration”. The scan host must reach every monitored subnet.
NetBox needs Python 3.12–3.14, PostgreSQL 15+ and Redis 6.0+ in current releases, plus a WSGI server and reverse proxy. Minor releases arrive frequently and plugins must track them, so budget a little time each quarter. If that maintenance is unwelcome, NetBox Cloud moves hosting to the vendor; prices are by quote at the time of writing, so check NetBox Labs’ pricing page.
Where each falls short
- phpIPAM: the interface and data model are simpler, so modelling cabling, circuits or complex device relationships is limited. Discovery is ICMP-based by default, so hosts that drop ping look offline.
- NetBox: no native scanning, a steeper start, and it can feel heavy if all you wanted was “who has .47?”. The value appears once other systems read from it.
Verdict
Pick phpIPAM if your problem is address hygiene: conflicts, undocumented statics, DHCP ranges nobody can explain. You want a register that scans your own subnets on a schedule, flags new hosts and shows utilization, with a UI the whole team can use after a short walkthrough.
Pick NetBox if you want a single model of sites, devices, interfaces and addresses that automation reads from, you have (or plan) scripts or pipelines that consume it, and you are willing to feed reality in through imports, integrations or a discovery add-on.
Some teams run both for a while: phpIPAM as the day-to-day address register, NetBox growing as the design record. That works only if one of them is clearly authoritative for IPs; otherwise you have rebuilt the two-spreadsheet problem with better software.