Monitoring Proxmox for client fleets
Monitoring one Proxmox cluster is easy. Monitoring fifteen of them for fifteen different clients is a different job: every client must be isolated from every other, half the networks overlap, alerts must land in your ticketing system with the right client attached, and someone eventually asks for a report with their logo on it. This guide covers the architecture patterns first and tools second. It is written by the maintainer of Pulse, which appears at the end as the worked example.
The four problems multi-client monitoring must solve
Whatever tool you pick, the architecture has to answer these four questions. Most monitoring pain MSPs hit with Proxmox traces back to one of them being answered by accident.
1. Isolation
Client A's technicians, dashboards, alerts, and audit trail must never leak into client B's view. That includes the subtle paths: a shared alert channel, a shared metrics database queried without a tenant filter, or an API token that can read more than one client.
2. Connectivity
Your monitoring runs in your infrastructure, the clusters run in fifteen networks you do not control end to end. Something has to cross that boundary in a way client firewalls and your security review both accept.
3. Alert routing
An alert is only useful once it is a ticket on the right client's board with enough context to act. Per-client routing, client identity stamped on every event, and deduplication so a flapping guest does not open forty tickets.
4. Client-facing output
Monthly reports, uptime summaries, and sometimes a read-only login for the client's own team. If the tool cannot produce something a client can see, you end up assembling screenshots by hand at month end.
Three architectures, and what each one costs you
Pattern 1: one monitoring stack per client, by hand
The default that grows out of "we set up monitoring for client A once". Each client gets their own instance of whatever you use, installed and upgraded separately.
Works because: isolation is absolute and overlapping client networks never matter, since each stack only sees one network.
Fails because: operational cost scales linearly. Fifteen clients means fifteen upgrades, fifteen alert-rule drifts, fifteen places to check when you change a webhook, and no single pane telling you which client is on fire.
Pattern 2: one shared instance, tenant-scoped inside
A single monitoring process holds every client, separated by the tool's own tenancy model: organisations, sites, or host groups with scoped access.
Works because: one upgrade, one rule set, one pane. Cheapest to run.
Fails because: isolation is only as strong as the tool's weakest scoping feature, and overlapping RFC1918 ranges collide the moment one process dials two clients that both use 192.168.1.0/24. A misconfigured permission is a cross-client data leak, which for an MSP is a contract problem, not just a bug.
Pattern 3: one isolated runtime per client, managed from one control plane
Each client gets a genuinely separate monitoring runtime, typically a container, but a provider-level control plane creates them, licenses them, upgrades them, and gives you the cross-client overview. Container-per-client is the model Pulse MSP implements, and you can build an equivalent yourself with enough compose files and discipline.
Works because: isolation is structural rather than configured. Each runtime holds one client's credentials and dials one client's network, so overlap never collides and a leak requires escaping a container rather than misreading an ACL. Upgrades and licensing stay centralised.
Fails because: it needs a Docker host and an ingress with wildcard TLS, and it is heavier per client than a shared instance. Below three or four clients the ceremony may not pay for itself.
Connectivity: what pulls, what pushes
Proxmox forces a mixed model, and knowing which direction each data source flows decides how much VPN plumbing you actually need.
| Source | Direction | What that means for client sites |
|---|---|---|
| Proxmox VE API | You pull | Needs a routed path from your side: the VPN, WireGuard, or overlay network you already run to that client. A scoped read-only API token, never root@pam. |
| Proxmox Backup Server | You pull | Same path as the VE API. Backup health is the thing clients actually pay you to guarantee, so it belongs in monitoring, not in a monthly manual check. |
| Host and Docker agents | Client pushes | Outbound HTTPS from the client to you. No inbound firewall holes at the client site, which makes the security conversation with the client short. |
Rule of thumb: pull what lives on the hypervisor management plane, push everything else. If a client site cannot host a VPN endpoint, an agent on a host inside the network can still push, and some providers run the entire client relationship on push agents plus a single jump path for the VE API.
Alerts that arrive as tickets, not as noise
Three properties make multi-client alerting workable, and they are worth testing in any tool before committing:
- Client identity on the wire. Every webhook payload should carry a stable client or tenant identifier so your PSA can route it without parsing hostnames out of free text.
- Deduplication and flap damping. A guest rebooting during a backup window must not open a ticket per state change. Look for event IDs your ticketing side can deduplicate on, and hysteresis before an alert fires at all.
- Signed delivery. If the webhook endpoint is reachable from the internet, payloads should be signed so your automation can verify the source.
The PSA mapping itself is usually the easy half: a webhook receiver that turns JSON into a ConnectWise or HaloPSA ticket on the right board. The hard half is upstream, keeping the alert stream quiet enough that nobody mutes it.
Client-facing reports and access
Two different needs hide under "can the client see it":
- Periodic reports. Uptime, capacity, backup success rate, incidents. If the tool can brand these with your logo, month end stops being a screenshot exercise.
- A login for the client's own team. Only sensible when the tenancy model guarantees they see exactly their estate. In per-client-runtime architectures this is safe by construction. In shared instances, audit it before offering it.
The worked example: Pulse MSP
Pulse implements pattern 3. A provider control plane runs on your Docker host and creates an isolated Pulse runtime per client workspace: separate dashboards, users, alerts, webhooks with the client stamped in every payload, audit history, and reports with your branding. Proxmox and PBS are polled through whatever path you already have to the client, agents push everything else outbound, and overlapping client networks never collide because each workspace dials only its own client.
You can evaluate it without talking to anyone: two client workspaces, free for sixty days, from a signed versioned bundle with a guided setup that checks your host before changing anything. You need a Docker host, a domain with a wildcard DNS record, and network paths to your clients. Paid plans start at $149 per month for five clients.
Comparing against a general-purpose platform you already run? There is an honest comparison at Pulse vs Checkmk for Proxmox monitoring.