NIPAP: an IP address manager built around prefixes, VRFs and regexp search

A prefix database first, with the web interface on top

NIPAP is described as a sleek, intuitive and powerful IP address management system built to efficiently handle large amounts of IP addresses, and it was developed at a fairly large service provider with operations throughout Europe. The readme says it suits large organisations with massive amounts of addresses just as well as smaller enterprises with simple needs, which is a claim worth testing against how the system is actually built. The core is a prefix database, and everything else is a way to query it. The feature list gives the scale it targets, very fast and scalable to hundreds of thousands of prefixes, and the interface is a Google-style search with advanced search by regexp and by IPv4 and IPv6 prefix. Native IPv6 support is called out with full feature parity with IPv4, which in an IPAM is a real engineering statement rather than a checkbox, because a dual stack design that treats IPv6 as an afterthought shows up immediately in the search and allocation paths.

The apt repository is the documented install route on Debian systems

The getting started section is short and assumes a Debian family system. You add the project repository to your sources.

    deb http://spritelink.github.io/NIPAP/repos/apt stable main extra

Then you install the three pieces by role: nipapd for the backend, nipap-cli for the command line and or nipap-www for the web pages. That three package split mirrors the architecture of the system, with a daemon holding the data, a command line client talking to it and a separate web front end. The readme also points to the Getting it page on the project site for the fuller picture. For people who would rather build from source, the Makefile at the top of the repository lists the subprojects it drives, which are nipap, pynipap, nipap-www, nipap-cli and whoisd, and it offers source, install, buildrpm and builddeb targets. The same area of the tree holds a Dockerfile.nipapd and a Dockerfile.www, plus an INSTALL file and a .hadolint.yaml, so container builds are part of the supported surface rather than an afterthought.

VRF support is what separates this from a subnet tracker

The feature that distinguishes NIPAP from most address management tools is native VRF support, allowing overlapping prefixes in different VRFs. In practice that means two sites can each hold a 10.0.0.0/8 without the database complaining, which is the situation any provider running a multi-tenant backbone hits within a year. Alongside that, the system supports documenting individual hosts, not just the prefixes they live in, and it provides statistics over used and free addresses so you can see consumption per block rather than a single global figure. The two features combine into the address request system, which lets users request a prefix and have a suitable one assigned automatically. For an organisation where the IP plan is a shared resource with a waiting queue, that workflow is the value, and it is the part that a spreadsheet cannot do at all.

XML-RPC in the middle, and three client libraries on top

NIPAP is not only a web application. The feature list calls out XML-RPC middleware, allowing easy integration with other applications or writing, and the repository layout shows why, with a jnipap directory for Java, an ojnipap directory for Oracle and a pynipap directory for Python, alongside the core nipap directory and the two front ends. The project also publishes a PyPI package for the Python client, with a badge pointing at pynipap. So the architecture is a service with a stable programmatic surface, and the three client libraries exist so that a Java or Oracle system, which are both common in service provider estates, can talk to it without speaking XML by hand. The CLI is described as being for the hardcore user, which is the usual way of saying it does everything the web interface does without the browser, and it is what the automation and the client libraries sit on top of.

Authentication is SQLite and or LDAP, not a built-in user database

The authentication line in the feature list is short and specific: flexible authentication using SQLite and or LDAP. That is a design decision with consequences, because it means the user store is either the same SQLite database the rest of the system uses or an LDAP directory you point it at, and there is no third option in between. For an organisation that already runs LDAP and wants central authentication and group membership to drive permissions, that is exactly right and the integration work is done for you. For a small deployment with no directory, the SQLite path is simple, but you should understand that the user database is then part of the same backup and upgrade story as the prefix data. The readme does not spell out the LDAP schema or the group mapping in the section shown, so the detail lives in the documentation directory of the tree, along with a separate Creative Commons licence file for the documentation while the code itself is MIT.

Pre-1.0, no releases, and a Makefile that still builds its own apt repository

The versioning section is unusually candid and is the thing to read before you build an integration. The project tries to adhere to the Semantic Versioning guidelines, admits it has messed that up some times, and then makes the key point: NIPAP has not reached 1.0 yet, which means there might still be substantial changes to APIs and similar, with the promise to keep such changes to a minimum but an acceptance that there will inevitably be changes as development progresses. There are no GitHub releases attached to the repository, so version tracking is a matter of the NEWS file and the master branch, and the Makefile has a bumpversion target that bumps the version to the latest entry in that NEWS file. The Makefile also builds its own apt repository, with debrepo-stable and debrepo-testing targets that copy packages between the two channels using reprepro, and both are gated on being on the gh-pages branch. The last push to the repository was on 2026-10-13, so the code is being worked on, and the project is MIT licensed for code with the documentation under Creative Commons.

Editorial conclusion

NIPAP fits an organisation that needs a real prefix inventory rather than a spreadsheet, that already runs its own IPv6, that wants overlapping prefixes in separate VRFs, and that has developers who will integrate against the XML-RPC layer or the client libraries. It does not fit a small site that needs a hosted service with a vendor behind it, because there are no GitHub releases and the project is still pre-1.0 with the readme saying substantial API changes are still possible. Before you install it, add the apt repository and install nipapd with nipap-cli and nipap-www, plan the authentication layer early because it is SQLite and or LDAP rather than a built-in user database, and read the versioning note so your integration can tolerate the API changes the project still expects to make.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. SpriteLink/NIPAP on GitHub