Self-Hosted IPAM for MSPs: Stop Running a Separate Tool

When you onboard a new client, one of the first things you're doing is building a mental map of their network. What subnets are they running? What's the gateway? Which IPs are pinned to critical infrastructure? And where does that information actually live?

For most MSPs, the honest answer is "spread everywhere" — a phpIPAM instance nobody keeps current, a spreadsheet someone started in 2019, a comment buried in a closed ticket. IP address management is foundational to day-to-day support, but it's almost always an afterthought.

The typical fix is to bolt on a dedicated IPAM tool. phpIPAM and NetBox are the most common open-source choices. Both are capable platforms. Both also require you to spin up, maintain, and cross-reference yet another self-hosted application — separate from your client documentation, separate from your asset records, separate from your credential vault.

There's a more practical approach.

What MSPs Actually Need from IPAM

Enterprise IPAM platforms are built for large networking teams managing hundreds of VLANs across carrier-scale infrastructure. MSP requirements are more focused:

• Track subnets per client, with gateway, DNS, and DHCP range
• Record which IPs are assigned to which devices
• Flag reserved ranges and document edge cases
• Make all of this visible to techs responding to incidents — fast

That's the core of it. You don't need BGP route injection or a REST API for Ansible playbooks. You need client-scoped IP records that live next to the rest of your client documentation.

The Real Cost of Running IPAM Separately

Every separate tool in your stack carries a maintenance cost. For open-source self-hosted IPAM, that means an additional container or VM to keep running, a separate URL that techs have to remember under pressure, schema migrations to manage on upgrades, and — crucially — no connection between the IP record and the actual device documentation it belongs next to.

There's also the context-switching cost. When something breaks at 2am and a tech is trying to figure out what's on a particular subnet, having to open a second application to check a separate system introduces friction at the worst possible moment. The IP data and the rest of the client record are about the same client — they should be in the same place.

IPAM as Part of Your Documentation Platform

Weavestream is a self-hosted, open-source IT documentation platform that includes IPAM as a built-in feature alongside asset management, a client credential vault, domain and SSL monitoring, a client portal, and role-based access control.

The underlying principle: your IP address records belong in the same system as everything else about a client. When a tech is troubleshooting a network issue, they shouldn't have to switch applications to check subnet assignments. That context should be one click away from the client's asset list and credential records.

Weavestream's IPAM lets you define subnets per client with gateway, VLAN, and DNS information, track IP assignments within each subnet, and keep all of it inside a Postgres-backed, Docker-deployed instance you control entirely. No per-seat pricing. No SaaS subscription. No client network topology data sitting on someone else's servers.

The Self-Hosting Case Is Particularly Strong for IPAM

There's a recurring debate in MSP tooling about self-hosted versus SaaS. For IPAM specifically, the argument for self-hosted is unusually straightforward.

IP address data is sensitive in a way that's easy to underestimate. It's a map of your clients' internal network architecture — subnets, gateways, device placements. Storing that in a third-party SaaS platform means trusting another vendor with network topology data across every client you support. Self-hosted means that information stays in your environment, under your backup policy, accessible only to your team.

phpIPAM and NetBox are both solid choices if you genuinely need deep IP management capabilities — route tracking, full DDI integration, automation hooks. But if what you actually need is client-scoped IP tracking that techs can reference during support work, running a full standalone IPAM tool is operational overhead for a problem that doesn't require it.

Tool Consolidation as an MSP Strategy

The broader issue here isn't IPAM in isolation. It's the compounding cost of running too many independent systems.

Every self-hosted tool you maintain has a blast radius when something goes wrong — an upgrade breaks, a container dies, a database needs recovery. When your documentation, IPAM, credential management, asset records, SSL monitoring, and client portal all live in one platform, there's less to maintain, less to cross-reference, and fewer places for information to fall out of sync.

More practically: when a new tech joins your team, there's one system to learn. When you're responding to an incident, there's one place to look. That operational coherence is worth more than it sounds.

Get Started

Weavestream is free, open-source under AGPL-3.0, and deploys on Docker with a Postgres backend. Most installs are up in under an hour.

Visit weavestream.io to see the full feature list and deployment documentation.