Your IT documentation platform is the single most valuable target in your stack — it holds client credentials, network maps, and admin contacts for every environment you manage. Weavestream already hardens the account layer with forced MFA, brute-force lockouts, and rate limiting. But there’s a simpler question worth asking first: should the internet at large be able to reach your login page at all?
For most MSPs, the honest answer is no. Your technicians work from the office, from home IPs you know, or through a VPN. Weavestream’s built-in IP access rules let you enforce that reality at the platform level — no reverse-proxy wizardry, no separate firewall appliance, no enterprise-tier upsell.
Allow and Deny Rules, First Match Wins
IP rules live at /admin/ip-rules and follow a model any network engineer will recognise. Each rule is a single IPv4 address (203.0.113.10) or a CIDR range (10.0.0.0/8), with an ALLOW or DENY action and a priority. Rules are evaluated in priority order — lowest number first — and the first match wins. If nothing matches, access is allowed by default.
That default-allow posture means you can adopt rules gradually. Two common shapes:
Denylist mode — leave the default open and add DENY rules for ranges you never want to see: a hosting provider’s abuse-heavy block, a country-level range that keeps showing up in your failed-login stats, a former contractor’s static IP.
Allowlist mode — the stricter posture most MSPs eventually land on. Add ALLOW rules for your office ranges, your VPN egress IP, and your technicians’ known networks at low priority numbers, then a single DENY 0.0.0.0/0 at a higher priority number. Traffic from a trusted range matches an ALLOW first and gets through; everything else falls to the catch-all DENY. Your documentation platform is now effectively invisible to the public internet.
Rule enforcement runs before authentication — a denied IP is rejected before Weavestream even looks at credentials. Credential-stuffing bots can’t probe accounts they can’t reach.
Blocked Means Blocked — Even the Login Page
A detail that separates this from naive implementations: Weavestream enforces IP rules at both layers of the stack. The API rejects every call from a denied IP with a 403 immediately. The web tier rejects HTML page renders too — a blocked visitor doesn’t get a login form with a polite error, they get nothing to type a password into at all.
The page layer refreshes its ruleset from the API every 30 seconds, so a new DENY propagates to page renders within that window, while API enforcement is instant. Static asset paths under /_next/* remain reachable by design — a blocked IP can pull anonymous JS and CSS bundles, but can’t reach any HTML page or any API endpoint.
And the failure mode is thought through: if the API is ever unreachable, the page layer fails open rather than closed. A broken backend can’t accidentally lock your entire team out of the platform.
The Self-Block Guard
Anyone who has managed firewall rules knows the classic mistake: you add a DENY, hit save, and your own session goes dark. Weavestream guards against this at the API level. Creating, editing, or deleting a rule is refused with a clear error if the resulting ruleset would block the IP you’re making the change from — and the error names the offending CIDR so you can see exactly what you almost did.
If you genuinely need to block a range that includes your own address, the escape hatch is deliberate: add a higher-priority ALLOW for your specific IP first, then the broader DENY.
If You Do Lock Yourself Out Anyway
The guard catches the obvious mistakes, but long-running tabs and programmatic rule changes can still land you on the wrong side of a DENY. Weavestream documents three recovery paths, easiest first: connect from a different IP (phone hotspot, alternate VPN exit) and edit the rule normally; shell into the API container and manage rules over localhost, which resolves as 127.0.0.1 and bypasses your DENY; or, as a last resort, disable the rule directly in Postgres.
That last option is worth pausing on, because it’s a self-hosting point in disguise. When a SaaS platform locks you out, recovery means a support ticket and someone else’s SLA. When your self-hosted platform locks you out, recovery means a shell and thirty seconds — the security configuration docs include copy-paste recipes for all three paths.
Every Change Is Audited
IP rules are a security control, so changes to them are treated as security events. Every create, update, and delete is written to Weavestream’s append-only audit log as security.ip_rule.create, security.ip_rule.update, or security.ip_rule.delete — with the actor, timestamp, and source IP.
Managing rules requires the dedicated IP_RULE_MANAGE capability, so you can let senior technicians tune access rules without handing out full admin. When an auditor asks who changed network access controls on the platform holding client credentials, and when, you have a queryable answer rather than a shrug.
One Prerequisite: Trustworthy Client IPs
IP rules are only as good as the IP they evaluate, and behind a reverse proxy that means the X-Forwarded-For chain has to be handled correctly. Weavestream is careful here: the TRUST_PROXY_HOPS setting tells the web tier how many proxy hops sit in front of it, forged forwarding headers from untrusted peers are ignored, and a startup warning flags likely-unsafe topologies.
You don’t have to take that on faith either. The Security Center’s connection diagnostics tab shows exactly how your current request was attributed — resolved client IP, socket peer, and whether forwarding was trusted — so you can verify attribution through your real proxy before you rely on it for access control.
Defense in Depth, Without Another Tool
None of this replaces MFA, and it shouldn’t. IP access rules are the outer ring: they shrink your attack surface from “the entire internet” to “networks I’ve named.” Forced MFA, lockouts, and the Security Center handle whatever gets through. Layered together, an attacker needs a valid credential, a valid TOTP code, and a connection from a network you’ve explicitly trusted.
Most SaaS documentation platforms gate IP allowlisting behind their most expensive tier — if they offer it at all. In Weavestream it’s simply part of the platform, because restricting who can reach your own infrastructure shouldn’t be a premium feature.
If you’re already running Weavestream, open /admin/ip-rules and start with a DENY for anything that’s been hammering your login page — the Security Center’s login activity view will tell you exactly which IPs those are. Not running it yet? The quickstart guide gets you self-hosted with Docker Compose in a few minutes.