Self-Hosted MSP Client Portal: Give Clients Access Without Giving Up Control

Most MSPs treat client portals as an afterthought — something bolted onto a ticketing system or hidden behind a SaaS dashboard the client never logs into anyway. That's a missed opportunity. A well-designed client portal reduces support calls, builds trust, and makes your operation look significantly more professional. The question is whether you want to pay a per-seat SaaS vendor to host that access, or whether you'd rather own it.

This post is about the latter.

What MSP Clients Actually Want Portal Access For

Before building or deploying anything, it's worth being specific about what clients actually need to see:

• Their documentation. Network diagrams, onboarding runbooks, ISP contacts, printer configurations — the kind of information that currently lives in a ticket or a shared folder nobody can find.
• Asset information. What machines do they have? What licenses are expiring? What does their network topology look like?
• Credentials. Some MSPs share client-specific credentials (Wi-Fi passwords, shared application logins) through the portal rather than over email.
• Domain and SSL status. Enterprise clients especially want visibility into when their certificates and domains expire, without having to ask you.

Most SaaS documentation platforms offer portal access for an additional tier, or bundle it into plans that cost $30–60 per user per month. For a 20-client shop, that math gets painful quickly.

The Problem With SaaS Client Portals

It's not just the cost. When you use a SaaS platform to host your client portal, you're making several implicit decisions:

Your client data lives on someone else's infrastructure. That includes credentials, network documentation, and asset records. Depending on your clients' industry, that may conflict with their compliance requirements.

You're dependent on the vendor's roadmap. If the portal feature gets gated behind a higher tier, deprecated, or changed in a way you don't like, your clients feel the friction.

Per-seat pricing scales against you. The more clients you onboard, the more expensive the platform gets — at exactly the moment your margin is tightest.

Self-hosting changes the equation. You control where the data lives, how it's backed up, and what clients can see.

What a Self-Hosted Client Portal Needs to Actually Work

A client portal isn't just "read-only access to your documentation tool." Done poorly, it's a confusing interface full of internal notes clients shouldn't see, or an empty shell with no useful information. Done well, it's a clean, scoped view of exactly what each client organization needs.

The technical requirements are:

• Strict organization isolation. Client A cannot see Client B's documentation, assets, or credentials under any circumstances. This has to be enforced at the data model level, not just the UI level.
• Role-based access control (RBAC). Different portal users at the same client might need different levels of access. A department head might need full read access; a contractor might only need a specific runbook.
• Read-only by default. Clients should be able to consume information, not edit it. The last thing you need is a client accidentally deleting documentation.
• No internal noise. Internal technician notes, staff-only documentation, and operational details should be invisible to client users.

How Weavestream Handles Client Portal Access

Weavestream is a self-hosted IT documentation platform built for MSPs, small teams, and homelabs. The client portal is part of the core platform — not a paid add-on.

When you set up a client organization in Weavestream, you control exactly what that client's portal users can access. Role-based access control is built in, so you can configure per-user permissions scoped to their organization. Clients log in and see their own documentation, assets, and other information — nothing else. Organization boundaries are enforced at the data layer.

Because Weavestream is self-hosted (Docker-first, Postgres-backed), their data never leaves your infrastructure. If a client asks where their documentation is stored, the answer is: on your servers, under your control.

The platform also handles domain and SSL certificate monitoring and IPAM, so a client's portal view can include current domain expiry dates and certificate status alongside their documentation — the kind of proactive visibility that reduces "is our website certificate okay?" support calls.

Running It in Practice

Deployment is straightforward if you're comfortable with Docker. The typical setup is a single docker-compose stack with Weavestream and a Postgres instance. You can put it behind a reverse proxy (Nginx, Caddy, Traefik) and issue a TLS certificate via Let's Encrypt.

For client onboarding, you create the organization in Weavestream, populate the documentation and assets, then provision portal user accounts for the client contacts who need access. RBAC settings let you scope exactly what each account can see before you hand over credentials.

The result: each client gets a URL, a login, and a clean view of their own environment. You get reduced inbound "what's the Wi-Fi password again?" tickets and a platform you actually own.

The Bottom Line

A self-hosted MSP client portal isn't a luxury — it's a differentiator. Clients who can log in and find their own documentation, check their asset list, or verify their SSL status are clients who trust that their MSP has things organized. And you don't need to pay a SaaS vendor $50 per user per month to offer that experience.

If you're ready to run a client portal on infrastructure you control, Weavestream is free to self-host and open source under AGPL-3.0. Spin up an instance, populate a client organization, and see what the portal experience looks like before you commit to anything.