phpIPAM: a PHP web app for the address space you actually run

What phpIPAM manages and who reaches for it

phpIPAM is a PHP web application for keeping track of IP addresses, subnets and the devices sitting behind them. The README states the ambition plainly: a light and simple IP address management application, built as an ajax front end using jQuery libraries, PHP scripts, JavaScript and some HTML5 and CSS3, with the note that a modern browser is preferred so the JavaScript renders quickly. That is the whole pitch, and for a network engineer who wants somewhere to ask what is plugged into switch port 14, a browser interface is often the right shape of tool.

The repository is the development tree rather than a release bundle. The top level has `install/`, `upgrade/`, `db/`, `api/`, `app/`, `functions/`, `js/`, `css/`, `doc/` and `misc/`, along with `config.dist.php` and `config.docker.php`. Plain text `INSTALL.txt` and `UPDATE` files sit at the root, and the README links to separate pages for features and tools, requirements and installation, the API guide, upgrades, and a demo site. GitHub reports the last push on 2026-09-24, and the repository is not archived.

The demo page credentials appear in the README, and the same pair is the default for a new instance: `Admin / ipamadmin`. Read that as a warning rather than a convenience. The README says so itself, and it is the first thing to change on a fresh install.

Branch layout tells you which versions still get fixes

The branch list is unusually explicit, and it is the most useful thing in the README for anyone deciding what to deploy. MASTER is the latest stable release, DEVELOP is where current work lands, and then there is a maintenance branch per minor version, each with its own supported PHP range: 1.8.x and DEVELOP cover PHP 7.2 through 8.5, 1.7.x and 1.6.x cover 7.2 through 8.3, 1.5.x and 1.4.x cover 5.4 through 7.4, and 1.3.x stops at 7.1. Branches back to 1.2 are marked obsolete apart from the ones already named.

The database side is equally specific. The README recommends Common Table Expression support highly, meaning MySQL 8.0 or later or MariaDB 10.2.1 or later, and notes that utf8mb4 support has been mandatory since v1.6.0, which puts the floor at MySQL 5.7.7. It also says plainly that untested PHP versions are unsupported and may cause compatibility issues, which is a rare thing to find written down in a README.

The practical read is that an old phpIPAM can sit on an old PHP for a long time, but you have to pick the branch that matches your runtime and then keep taking that branch's releases. A repository with nine branches in different states of support is a maintenance commitment, not a one-time install.

Docker images exist, and the README defers setup to the docs

The README contains no runnable install command. It points at the installation document on phpipam.net and notes that community maintained Docker images are published at `https://hub.docker.com/u/phpipam`. The presence of `config.docker.php` next to `config.dist.php` in the tree suggests the container path and the tarball path share most of their configuration surface without being identical.

One CLI tool is documented inline, and it is the one you are most likely to need soon after installing, because the default admin account is published:

php functions/scripts/reset-admin-password.php

Run it from the command line and it prompts for the new password. The `functions/scripts/` path is in the tree, so the script ships with the application rather than arriving with a distribution packager.

What the README does not settle is the sequence itself: which web server to point at, where the document root goes, what belongs in `config.dist.php`, and how the installer is invoked. Those answers live in the linked installation document. If you are weighing phpIPAM for a network you do not yet own, that document is part of the evaluation rather than an afterthought.

The API is the integration surface, and its permission history is the warning

phpIPAM has an `api/` directory and a documented API guide, which is what makes it scriptable rather than a browser toy. The release notes for the 1.8 line are where that surface gets audited, and the list is long enough to be instructive.

Version 1.8.2, published 2026-08-16, lists one bugfix, a rack dropdown failing to populate while editing a device, followed by twelve security entries: an API authentication bypass via object cache key collision, disabled API endpoints still reachable, an API read only permission bypass, arbitrary local file inclusion in an API controller, temporary shares enumerating all addresses, temporary share creation missing permission checks and missing CSRF checks, second-order SQL injection in custom field reordering and again in NAT fields, subnet permissions rewritable by any authenticated user, and cross-subnet and ping insecure direct object references. Version 1.8.3, published 2026-09-09, made dynamic authentication API endpoints return 409 and closed two more: 2FA activation bypassing CSRF checks, and insecure direct object references.

Two things follow for an adopter. The API exists and is worth automating against. And on a 1.7.x or earlier install, the permission model around temporary shares, custom field reordering and subnet permissions is not the one these releases assume, so reading the notes for your own version is not optional diligence.

Behind a reverse proxy, one flag decides whether login works

A section devoted to one specific failure mode says something about how a project gets debugged. The README describes infinite login loops behind a reverse proxy and gives the fix: since v1.6.0, either set the config flag or use the Docker environment variable to accept the X_FORWARDED_ headers.

$trust_x_forwarded_headers = true;
IPAM_TRUST_X_FORWARDED=true

The same section carries a warning that is easy to skim past. Those headers must be filtered or overwritten by the reverse proxy, because otherwise an end client can set them:

X_FORWARDED_FOR
X_FORWARDED_HOST
X_FORWARDED_PORT
X_FORWARDED_PROTO
X_FORWARDED_SSL
X_FORWARDED_URI

This is the one place in the README where the project asks for a security decision rather than describing a feature. If your proxy appends to X_FORWARDED_FOR instead of replacing it, and a client can supply the first value, then the application is trusting attacker-supplied information about the client's address. The one-line fix for the login loop is easy. Getting the proxy to overwrite rather than append is the part that needs checking against your own infrastructure.

What the README leaves to the documentation site

The README is short and does not try to be a manual. It covers what the application is, which branches exist, which PHP and database versions each branch supports, the password reset script, the reverse proxy flag, the default credentials, where the community Docker images live, and the license. It links out for features and tools, requirements and installation, the API guide, upgrades, and the changelog at `misc/CHANGELOG` plus the roadmap at `misc/Roadmap`. A `SECURITY.md` file and a `db/` directory sit in the tree, and the repository description calls it the development repository, with contact details for the maintainer and a note thanking the team that donates the VPS used for development and for the demo site.

On licensing there is a discrepancy worth naming. The README says phpIPAM is released under the GPL v3 license and points at `misc/gpl-3.0.txt`, while GitHub shows no license value for the repository at all. Both facts stand side by side: the project states GPL v3 in its own documentation, and the metadata does not repeat it. For anything that matters legally, read the license file in the repository rather than the badge.

So the honest summary of the README is this. It settles the version matrix and the reverse proxy gotcha, which are the two things that actually go wrong during deployment, and it defers installation detail, feature documentation and API semantics to phpipam.net.

Editorial conclusion

phpIPAM fits a network team that wants a browser front end over a MySQL or MariaDB address book and nothing more exotic: it installs from a tarball or a community Docker image, it ships a documented API, and its branches track which PHP versions still get fixes. It is the wrong tool if you want active discovery, DHCP scope handling or a schema that is not SQL, since none of that appears in the repository. Start on the 1.8 branch rather than develop, read the release notes for the version you plan to run, and change the default Admin credentials before the instance is reachable from anywhere but your own machine.

Frequently asked questions

Official sources

1. Issues
2. phpipam/phpipam on GitHub
3. Project website
4. README
5. Releases