MSP / provider access

Run Pulse for every client from one account.

Standard self-hosted plans cover one Pulse environment. Pulse MSP gives providers a single Pulse Account to run many clients, with an isolated Pulse runtime per client workspace: separate dashboards, alerts, webhooks, users, audit history, and reports. It runs on your infrastructure, and nothing in a client workspace phones home to Pulse.

Start the free evaluation See what you deploy

Two client workspaces free for 60 days. The verified setup guide is the start: no form, card, or approval is required. Paid plans start at $149/mo for 5 clients, about $30 per client per month.

PROVIDER Your Pulse Account CLIENT A Workspace own dashboards own alerts own users own audit history ISOLATED RUNTIME CLIENT B Workspace own dashboards own alerts own users own audit history ISOLATED RUNTIME CLIENT C Workspace own dashboards own alerts own users own audit history ISOLATED RUNTIME
Isolation

A runtime per client

Each client workspace is its own isolated Pulse runtime with its own data directory, not a tag filter inside one shared install.

Hosting

Provider-hosted by default

You run the workspaces on your own infrastructure, next to your clients. Pulse-hosted operation is available by request.

Accountability

Per-client audit trails

Separate users, audit history, and reports per workspace, so client boundaries hold up under scrutiny.

Every workspace is full Pulse

Client workspaces are not cut-down views. One client runs Proxmox, another runs Docker on Podman hosts, a third runs Kubernetes: each workspace monitors that client's whole stack, with the same Pulse the homelab community runs.

Pulse Docker overview in a client workspace showing five container hosts with CPU, memory, disk, uptime, and swarm roles
A Docker-heavy client: hosts, containers, swarm roles.
Pulse Kubernetes overview in a client workspace showing development, production, and staging clusters with node, pod, and deployment counts
A Kubernetes client: clusters, nodes, pods, deployments.
The public demo is one ordinary Pulse instance, which is exactly what a single client workspace looks like from the inside. Open the demo and check that claim rather than take it. The provider portal above it is not part of the demo.

What you run as the provider

Clients get full Pulse; you get the layer above it. Your Pulse Account portal holds the whole client fleet, and every workspace can produce client-ready reports.

The provider portal, recorded. Six clients, one with a critical alert, opened in one click.

One portal for the whole fleet

Your Pulse Account lists every client workspace with its setup status, live alert rollup, and runtime health, and tells you which client to review next. Critical alerts surface at the fleet level, so the morning check is one screen, not ten logins.

  • Setup, alerts, and health per client at a glance.
  • A repeatable onboarding path for each new client.
  • Open any client workspace with one click when something needs attention.

Reports your clients actually see

Every workspace generates scheduled PDF performance reports covering uptime, resource usage, and fleet health over the period, ready to land in a client inbox. With white-label, they carry your name and logo, not ours.

  • Per-client scheduled reports from each workspace.
  • Uptime and resource trends over 24h, 7d, or 30d periods.
  • White-label branding available as a request-assisted add-on.
Cover of a white-labelled Pulse client report titled Harbour Logistics Monthly Infrastructure Report, branded with a fictional provider logo and name
A client report cover carrying the provider's branding (example provider and client).

What you actually deploy

MSP ships as a supported deploy bundle, not a pile of containers you wire together. One Docker Compose stack on one host gives you Traefik ingress with wildcard TLS, a hardened Docker socket proxy, and the control plane that provisions client workspaces.

# Check the host before you commit to it $ ./setup.sh --preflight # Bring up the provider control plane $ ./setup.sh # Prove a fresh install end to end $ ./run-install-proof.sh # Upgrades take a backup first, every time $ ./upgrade.sh

Day-two operations are part of the product

The things that decide whether a monitoring tool survives contact with a real client fleet are shipped and documented, not left to you.

  • Preflight checks that fail before install, not during it.
  • Upgrades that take a backup first, plus restore commands that bring workspaces back from backup or disk.
  • An install-proof script that verifies a fresh deployment end to end.
  • Portal sign-in by one-time link rather than another password to rotate when staff leave.

Client networks stay separate

Agents at client sites push in over HTTPS. Proxmox and PBS are polled outward through your existing VPN or tunnel, so nothing at a client site needs an inbound hole for them.

  • Overlapping RFC1918 ranges across clients never collide, because each workspace only dials its own client's addresses.
  • Duplicate hostnames across clients never collide either.

The management port is not the agent port

Management UI and agent check-in run on separate, separately firewalled ports. The agent port serves only report and command routes; login and management APIs return 404 there.

  • Keep the management port on your staff network or VPN only.
  • Agent tokens carry least-privilege scopes and cannot manage the instance.

Alerts route per client

Each client's Gotify server, Slack channel, or PSA endpoint only ever sees that client's alerts.

  • Webhook payloads carry the firing client's ID and name, so one central PSA endpoint can route by client.
  • Signed deliveries and event-ID deduplication for ticket bridges.
On a fresh install the setup script makes one outbound call to Pulse to fetch your evaluation licence. The signed provider bundle sends only the public half of a signing key generated on your host. It never sends your contact details, client data, inventory, or credentials, and you can skip the call entirely on an air-gapped host. After that the control plane issues its own client entitlements and nothing in a client workspace ever calls us.
The full provider operations guide, including the firewall baseline and the post-setup validation checklist, is public: docs/MSP.md on GitHub.

Plans

Start on the free evaluation and pay when you outgrow it. Published prices, no discovery call, no custom quote for the standard tiers. Every plan covers unlimited monitored systems inside each client workspace, so you are charged by client, not by endpoint. Annual is two months free.

Evaluation

Free for 60 days, two client workspaces

Start from the verified setup guide. It downloads the signed provider bundle, checks its integrity, and runs the guided setup on your host. The setup issues its own evaluation licence, so there is no form, card, or approval between you and the first two client workspaces.

Before you start An Ubuntu 24.04 host, a domain you control, DNS access, and ports 80 and 443.
Open the verified setup guide

Want setup help?

Leave a work email and I can help if the host, DNS, or first client setup stalls. This is optional and stays separate from anonymous licence issuance.

The evaluation licence request sends only the public half of the signing key created on your host. It does not send these contact details, client inventory, credentials, or private key.

Starter

$149/mo or $1,490/yr

Up to 5 client workspaces, provider-hosted. About $30 per client per month.

Request MSP Starter
Growth

$249/mo or $2,490/yr

Up to 15 client workspaces, provider-hosted. About $17 per client per month.

Request Growth
Scale

$399/mo or $3,990/yr

Up to 40 client workspaces, provider-hosted. About $10 per client per month.

Request Scale
Run it free before you buy
30-day money-back guarantee
Secure checkout by Stripe
Cancel renewal anytime, no notice period
Client limits block, they never bill extra
Client data stays on your infrastructure
Thirty days rather than the usual fourteen, because standing up a provider deployment and onboarding a couple of clients takes longer than installing Pulse once. If you walk away, client workspaces drop back to Community rather than going dark, so nobody's monitoring stops while you decide. Full detail in the terms.
Larger fleets, white-label, or Pulse-hosted rollouts are sized individually: tell me what you are running.

Choose MSP when

  • You operate Pulse for multiple paying clients and need clean per-client boundaries.
  • Clients need their own dashboards, alert routing, users, and reports.
  • You want one commercial relationship covering the whole client fleet.

Stick with self-hosted plans when

  • You monitor one environment, even a large one: Community, Relay, or Pro covers it.
  • Your "clients" are internal teams happy to share one workspace and one audit trail.
  • You are still evaluating Pulse: start free, then move to MSP when real client boundaries appear.

Questions providers ask first

How does Pulse reach my clients' networks? +
Two directions, and you control both. Agents on client hosts push out over HTTPS to your agent ingest port, so client sites need no inbound holes. Proxmox and PBS are polled the other way, from your side through the VPN or tunnel you already run to that client. Because each workspace only ever dials its own client's addresses, overlapping private IP ranges across clients never collide.
Does any client data reach Pulse? +
No. On a provider-hosted deployment every client runtime runs on your infrastructure and leases its entitlements from your own control plane, so nothing in a client workspace calls out to us. Metrics, logs, alerts, and reports stay on your host. The core is MIT-licensed and on GitHub if you want to check that claim rather than take it.
What happens when I hit the client limit? +
Creating the next workspace is blocked. You are never silently billed for going over, and nothing stops monitoring for the clients you already have. Move up a tier when you actually need the room, and the existing workspaces carry on untouched.
What happens to my clients if I stop paying? +
Nothing gets deleted and nothing goes dark. After the licence expires and the grace period passes, client runtimes fall back to Community behaviour, so core monitoring keeps running without the paid capabilities. Renew and restart the control plane and they pick their entitlements back up.
Can a client log in and see only their own workspace? +
Yes. Each workspace is a full Pulse instance with its own users, roles, and audit history, so giving a client access to theirs gives them nothing about anyone else's. Most providers keep clients on scheduled reports instead, but the option is there.
What do I need to run this? +
One Docker host you control, a wildcard DNS record, and network paths to your clients. The bundle brings its own Traefik ingress and TLS, and the guided setup script has a preflight mode that checks the host before it changes anything. If preflight is unhappy you have lost five minutes, not an afternoon.
Is this the same Pulse the homelab crowd runs? +
The same, with a provider layer above it. Every client workspace is ordinary Pulse monitoring Proxmox, Docker, Kubernetes, TrueNAS, and vSphere, which means the thing watching your clients is the thing several thousand people already run against their own infrastructure every day.

Request MSP Starter, Growth, or Scale

For a third client and beyond. Tell me what you are running and I reply from [email protected], usually the same day, with a direct Stripe checkout link for the published price. No discovery call, no quote to negotiate. The deploy bundle is public either way, so you can be running two clients before you ever contact me, and you get 30 days to decide it was the right call.

I read every one of these myself.
Prefer email? Write to [email protected]. Not a provider? See self-hosted pricing for single environments.