Every MSP hits the same moment. A client calls to ask whether their SSL certificate is still valid, or needs the VPN config they’ve requested three times before. You answer the question and think: they could have just looked this up themselves.
The answer is a client portal. But every option you find is a SaaS add-on, bundled into a platform you’re already paying per-seat for, with limited control over what clients see.
There’s a self-hosted path. This article explains what it looks like.
What an MSP Client Portal Actually Needs to Do
The purpose of a client portal isn’t to dump your entire documentation stack into a client-facing interface. It’s to surface the right information to the right people — without exposing credentials, internal runbooks, or other clients’ data.
That means a useful client portal needs three things:
Scoped visibility. Clients should see their own documentation, assets, and status. They should not see your internal notes, other clients’ data, or anything your team has marked as internal-only. Access must be strictly per-client, not per-platform.
Relevant information. What clients actually want is practical: is my SSL cert valid? When does my domain expire? What are the specs on this server? A portal that just surfaces a documentation wiki is noise. One that surfaces their assets, monitored services, and relevant docs is useful.
No internal access. A client portal is not a technician account with permissions stripped down. It’s a separate surface with a different access model. Giving a client a login to your main documentation platform — even with limited permissions — is a category error.
Why SaaS Client Portals Fall Short
The major MSP documentation platforms offer client portal features, but they come with caveats. IT Glue’s client-facing features are tied to their per-seat model. Hudu’s depth depends on your tier. Passportal bundles a client view inside N-able’s ecosystem.
In every case, the portal lives in someone else’s infrastructure. Your client data is in a cloud database you don’t control, with terms that can change at renewal. The per-seat math is also unforgiving: once you factor in client user seats, the cost of a “free” portal feature climbs fast.
Self-Hosted Changes the Equation
When your IT documentation platform is self-hosted, the client portal is just another access tier on infrastructure you already run. There’s no per-seat charge for client logins because there’s no vendor metering. The data stays in your database, on your server, under your backup policy.
Weavestream’s client portal is built on the same platform as everything else — the asset management, IPAM, credential vault, SSL and domain monitoring, and knowledge base. When you enable client access, clients see a scoped view of their own environment: their assets, their monitored domains and certificates, their relevant documentation. Your internal data stays internal.
Role-based access control is what makes this work cleanly. Weavestream’s RBAC lets you define exactly what each client can see and do — read-only access to their own assets, visibility into their SSL/domain status, access to selected documentation — without touching anything else in the platform.
What Clients Actually See
A self-hosted client portal isn’t a whiteboard for you to fill with everything you know about a client’s environment. It’s a curated view. For most MSPs, the most useful things to surface are:
Domain and SSL monitoring status. Clients often don’t know when their certificates or domain registrations expire until something breaks. A portal that shows them their monitored services gives them visibility without requiring them to call you, and it gives you a paper trail showing you were watching.
Asset inventory. Clients routinely forget what hardware they own, especially when it’s time to talk about refresh cycles. A read-only view of their asset list — with specs, location, and warranty status — is practical information they’ll actually use.
Documentation they’re meant to have. VPN setup guides, acceptable use policies, vendor contacts, escalation procedures — documentation that belongs to the client in the first place. Hosting it in the portal means one source of truth instead of emailing them the same PDF quarterly.
The Deployment Reality
A self-hosted client portal requires running your own infrastructure. Weavestream deploys as a Docker container backed by Postgres — if you’re already running a self-hosted documentation stack, this is a standard deployment. You own the maintenance, but you also own the data.
The argument for self-hosting isn’t ideological. It’s operational: a portal integrated with your documentation, no separate product bolted on, no per-seat charge for client accounts, and data that stays where it belongs.
Weavestream’s client portal is included with the platform — no separate licensing, no per-seat fees for client accounts. If you’re evaluating self-hosted MSP documentation, start at weavestream.io.