Your IT documentation platform holds the keys to every client environment you manage — credentials, network diagrams, admin contacts, the works. That makes it one of the most attractive targets in your entire stack, and yet most MSPs have no visibility into who’s actually logging into it, from where, or how many times someone just failed a password attempt.
Weavestream’s Security Center closes that gap. It’s a real-time dashboard for authentication activity, active sessions, and security events across the platform — built into the same self-hosted instance where your documentation already lives, not a bolt-on SIEM you have to pay for and pipe logs into separately.
Login Activity, Not Just an Audit Trail
Weavestream already has an append-only audit log for tracking data changes — who edited an asset, who revealed a password. The Security Center is a different lens: it’s about authentication events, not data mutations.
The Login activity tab breaks down successes, failed password attempts, and failed MFA attempts over a configurable window (1h, 6h, 24h, 72h, or 7 days, capped at the most recent 200 events per view). You can slice the same data two ways — by source IP or by target email — so a spike in failed attempts against one technician’s account looks different from a spread of failures across many accounts hitting from a single IP, which is usually the signature of a credential-stuffing attempt.
Events are colour-coded for a reason: green for a successful login or MFA verification, yellow for a failed MFA code, red for a failed login attempt. At a glance, you know whether you’re looking at normal noise or something worth investigating.
Lockouts and Rate-Limit Blocks, Made Visible
Weavestream already enforces brute-force protection under the hood — five failed attempts within fifteen minutes locks out an IP or email — but until the Security Center, that protection was invisible unless you went digging through logs. Now it’s a tab.
The Lockouts view shows every account and IP currently locked out, plus anything approaching the threshold (flagged as “Warming” so you can see trouble building before it trips). You get the failure count, the lock state, and the time remaining until the lockout resets — by IP or by email.
The Rate-limit blocks tab shows active throttle blocks from the platform’s rate limiter: which identity got blocked, which throttler triggered it, and how long the block lasts. By default Weavestream runs a soft 60-second rolling window without hard blocks, so this tab is usually empty — which is itself a useful signal. If it’s not empty, something unusual is happening against your login endpoint.
Active Sessions You Can Actually Kill
Every login creates a server-side session record, and the Active sessions tab lists every non-revoked, non-expired session across your entire user base — not just your own. For each one you get the user’s name and email, their role, MFA state (off, enabled, enrolled, or pending), IP address, user agent, and when the session started.
If a technician’s laptop gets stolen, or you suspect a session token leaked, you find the row and click Revoke. The user is signed out on their next request — no waiting for a JWT to expire, no relying on the person to log out themselves. Revocation is fully audited, and by design you can’t revoke your own session from this view; that has to happen from your own profile page, which prevents an admin from accidentally locking themselves out mid-incident.
This matters a lot for MSPs specifically, because your users aren’t just internal staff — they’re contractors with time-boxed access and client-portal users who may be using shared or less-secured devices. Having a single place to see and kill any active session, regardless of who it belongs to, is the kind of control that’s easy to take for granted until the moment you need it urgently.
Egress Blocks: Watching the SSRF Guard Do Its Job
This is the tab most documentation platforms don’t have at all, because most documentation platforms don’t make outbound HTTP requests on your behalf. Weavestream does — for domain and SSL monitoring, for integration syncs — which means it needs protection against server-side request forgery (SSRF): a class of attack where a malicious input tricks the server into making requests to internal infrastructure it shouldn’t be able to reach.
Weavestream’s SSRF guard blocks outbound requests to private IP ranges (10.x.x.x, 172.16–31.x.x, 192.168.x.x), loopback addresses, and link-local addresses — including cloud metadata endpoints, a favorite target for SSRF exploitation in cloud environments. The Egress blocks tab shows you every request the guard has stopped, with a timestamp, the resolved IPs, the block reason, the matched CIDR range, and the source user agent.
If you do need to allow a specific private range — say, monitoring an internal domain that legitimately resolves to an RFC1918 address — you can allowlist it via the EGRESS_ALLOWED_PRIVATE_CIDRS environment variable. But the default posture is closed, and you can watch it working instead of just trusting that it is.
Why This Belongs in a Self-Hosted Platform
A lot of MSPs already pay for a SIEM or a security monitoring tool for their own internal stack. Bolting one onto a SaaS documentation vendor usually isn’t an option — you get whatever visibility the vendor decides to expose, if any, and you’re trusting their infrastructure with your client credentials on top of it.
Because Weavestream is self-hosted, the Security Center is reading data that lives in your own Postgres and Redis instances. There’s no separate log shipping pipeline, no third party holding a copy of your login activity, and no additional per-seat security-monitoring fee. It’s part of the platform you already run.
Access to the Security Center is capability-gated — you need SECURITY_READ to view it, and USER_MANAGE to revoke sessions from within it — so turning this visibility on for your security-conscious staff doesn’t mean handing out broader admin rights than they need.
Getting Started
If you’re already running Weavestream, go to Admin → Security to open the Security Center. Start with the Login activity tab and get a baseline for what normal traffic against your instance looks like — then you’ll notice immediately when it stops looking normal.
New to Weavestream? The quickstart guide gets the full stack running with Docker Compose. The Security Center works out of the box once you’ve assigned the SECURITY_READ capability to the accounts that need it — no extra services to deploy, no logs to ship anywhere.