Can Beszel monitor Proxmox? Yes, at the host level. Proxmox VE is Debian underneath, so the Beszel agent installs on it like any other Linux server and reports CPU, memory, disk, disk I/O, network, load average, temperatures and S.M.A.R.T. health. What it does not do is talk to the Proxmox API, so you get no per-VM or per-LXC-guest breakdown.

That one sentence is the whole answer, and it is also the part most write-ups get wrong. The rest of this post covers how to install the agent on a Proxmox node, why the hub should not live on the node it is watching, exactly what you see per install location, and whether Beszel is worth running next to Proxmox’s own graphs.

I checked everything below against Beszel v0.18.7 (the current release as of August 2026) and the project’s own docs and issue tracker in August 2026.

Can Beszel monitor Proxmox?

Yes. Beszel treats a Proxmox VE node as a plain Linux host: you install the agent on the node, it appears in the hub, and you get that machine’s metrics with history and alerting. What you do not get is Proxmox-aware monitoring. Beszel has no Proxmox API integration, so it never lists your VMs or LXC guests.

Beszel is a single Go binary under an MIT license with about 22,000 GitHub stars, and the agent idles at roughly 10-15MB of RAM. That is small enough that nobody notices it on a hypervisor. Per the project’s own metric list, the agent collects:

For a Proxmox node that covers the things that actually kill a hypervisor: a full ZFS pool, a dying disk, a box thermally throttling in a closet, or memory pressure from one over-provisioned VM.

How do you install the Beszel agent on a Proxmox host?

Run the agent install script directly on the Proxmox node shell as root, paste in the hub’s public key and token, and the agent registers itself as a systemd service. It takes about a minute. Do not install it inside every guest first: the node is where the useful signal is. Proxmox nodes are usually a machine you own outright or a rented dedicated box rather than a rented slice, and VPS vs dedicated server covers where that line falls.

1. Stand up the hub somewhere else. More on why in the next section. Once it is up, open Settings and grab the public key and a universal token (/settings/tokens, available since Beszel 0.12.0).

2. On the Proxmox node, run the install script:

curl -sL https://get.beszel.dev -o /tmp/install-agent.sh \
  && chmod +x /tmp/install-agent.sh \
  && /tmp/install-agent.sh

The script takes -k for the public key, -p for the port, -t for the token, and --auto-update if you want it to keep itself current. It installs a beszel-agent systemd unit, so systemctl status beszel-agent is your first debugging stop.

3. Check the connection. The agent dials out to your hub over a WebSocket at /api/beszel/agent-connect, so the hub needs a reachable URL but the Proxmox node does not need any inbound port opened. If that WebSocket drops, the agent falls back to exposing an SSH tunnel on port 45876 for the hub to pull from. That outbound-first design is why a homelab node behind NAT works without port forwarding.

One gotcha if you are proxying the hub yourself: your reverse proxy must pass the Upgrade and Connection headers. Without them the dashboard loads fine and agents silently never connect, which is a genuinely annoying 20 minutes to diagnose.

Should the Beszel hub run on the Proxmox box itself?

No. If the hub lives on the machine it is watching, it dies with that machine. The node kernel panics, the ZFS pool fills, a reboot hangs on a failed disk, and the one system that was supposed to email you is down too. You find out the next morning. Monitoring that shares a failure domain with the thing it monitors is not monitoring.

This is the single most common Proxmox homelab mistake, and it is easy to make because Proxmox is right there with spare capacity. It feels wasteful to put a 512MB dashboard anywhere else. But the hub is not just a dashboard, it is your notification path: alerts for CPU, memory, disk, bandwidth, temperature, load average and status all fire from the hub. Lose the hub, lose the alert.

So the hub belongs on something that is not your Proxmox node. Three options that actually work:

Where the hub runsSurvives the node dyingCostSetup
On the Proxmox nodeNoFreeFast, and wrong
A second box or Pi at homeYes, unless the power or ISP goesHardware + powerYou wire up TLS and remote access
Off-site pod or VPSYes, including a full-site outageFrom $3/moDepends on the host

If you want the off-site version without building it, InstaPods runs Beszel as a 1-click app on the $3/mo Launch plan (1 vCPU, 512MB RAM, 10GB disk). The hub boots pre-installed with a public HTTPS URL, the proxy already passes WebSocket upgrade headers so agents connect, SSH access is included, and there is a nightly backup of the hub database. Your Proxmox agent dials out to it, so nothing at home needs a port forwarded. The longer version of that setup is in managed Beszel hosting.

The honest framing: any off-box location works. A $3/mo pod is just the cheapest one where you do not also own the nginx config, the certificate renewal and the dynamic DNS.

What does Beszel show for Proxmox VMs and LXC guests?

Host-level metrics only, unless you install an agent inside each guest. Beszel does not query the Proxmox API, so it never enumerates guests. Agents inside full VMs report correctly because a VM has its own kernel. Agents inside LXC guests report the host’s total memory, not the guest’s limit, which is the one result that surprises people.

Here is what you actually see, by install location:

Agent installed onCPUMemoryDiskNotes
Proxmox VE nodeNode totalNode total, ZFS ARC includedNode pools and partitionsThe useful one
Inside a VM (KVM)The VM’sThe VM’sThe VM’sBehaves like any normal server
Inside an LXC guestRoughly correctShows the node’s RAMRoughly correctKnown limitation

The LXC memory behaviour is not a bug in your setup. An LXC guest is a namespace on the host rather than a separate machine, so it reads the host’s memory even when you have set a limit, and every agent on the same node ends up reporting the same figure. That is tracked in henrygd/beszel #176, which is still open, and a follow-up request to read guest stats through the Proxmox API (#633) was closed as a duplicate of it. Assume it is not solved today.

If per-VM and per-LXC-guest detail is what you came for, that is Pulse’s job, not Beszel’s: Pulse auto-discovers nodes, VMs and guests through the Proxmox API. The split is covered in Beszel vs Pulse. Most people running Proxmox plus a couple of other boxes end up with both, and about $6/mo of pods total.

Beszel vs Proxmox’s built-in graphs: do you need both?

If a single Proxmox node is your entire infrastructure, you probably do not need Beszel. Proxmox VE already draws RRD graphs per node, per VM and per guest with hour, day, week, month and year views, and it breaks down per-guest usage in a way Beszel cannot. Beszel earns its place when you have more than one machine, or when you want alerts.

Two things Proxmox’s own graphs do not give you:

One view across machines that are not Proxmox. A Proxmox node, a $5 VPS, a Raspberry Pi and a Docker host are four separate dashboards in the built-in tooling. In Beszel they are four rows on one page, which is the entire reason to run a hub.

Threshold alerting. Proxmox VE’s notification system is event-based: package updates available, cluster node fenced, replication job failed, backup succeeded or failed, mail for root. Per its own documentation those are the events it emits. There is no built-in “tell me when this node sits above 90% memory for 10 minutes.” Beszel does exactly that for CPU, memory, disk, bandwidth, temperature, load average and status.

So the split is: Proxmox graphs for per-guest detail on one node, Beszel for cross-machine history and alerting. They overlap on the node’s own CPU and memory graph, and nowhere else. Neither one tells you whether the services running on those guests still answer from outside, which is what an uptime monitor is for. If you want the wider field of tools first, our roundup of the best server monitoring tools tests seven of them side by side, and Beszel vs Prometheus + Grafana covers the step up if you outgrow simple thresholds.

The setup I would actually run

For a homelab with one Proxmox node and a couple of other boxes:

  1. Beszel hub off-box, on a $3/mo pod or a second machine. Never on the node.
  2. Beszel agent on the Proxmox node itself, plus one on each non-Proxmox server.
  3. Agents inside VMs only where you care about that VM specifically. Skip agents inside LXC guests unless you accept the memory caveat.
  4. Pulse alongside it if you need per-VM and per-LXC-guest visibility.
  5. Alerts configured on memory and disk before you need them, not after.

Total: about $3/mo for the hub and 10-15MB of RAM per agent.

FAQ

Can Beszel monitor Proxmox?

Yes, at the host level. Proxmox VE runs on Debian, so the Beszel agent installs on the node like any Linux server and reports CPU, memory, disk, disk I/O, network, load average, temperature and S.M.A.R.T. health with history and alerting. Beszel has no Proxmox API integration, so it does not enumerate your VMs or LXC guests.

Does Beszel show per-VM and per-LXC stats on Proxmox?

Not by itself. Beszel only sees the machine each agent runs on. An agent inside a full VM reports that VM’s metrics correctly. An agent inside an LXC guest reports the Proxmox host’s total memory rather than the guest’s limit, because an LXC guest is a namespace on the host. That is tracked in henrygd/beszel issue #176, still open as of August 2026. For per-VM and per-guest visibility through the Proxmox API, use Pulse.

Where should the Beszel hub run if I use Proxmox?

Anywhere except the Proxmox node you are monitoring. The hub is your alerting path, so if it shares a machine with the thing it watches, a node failure takes out both and no alert is ever sent. Run it on a second box, a Pi, or an off-site pod. InstaPods runs Beszel as a 1-click hub from $3/mo on 1 vCPU, 512MB RAM and 10GB disk.

How do I install the Beszel agent on a Proxmox host?

Run curl -sL https://get.beszel.dev -o /tmp/install-agent.sh && chmod +x /tmp/install-agent.sh && /tmp/install-agent.sh as root on the node shell. Pass -k for the hub public key, -t for a universal token and -p for the port. The script installs a beszel-agent systemd service. The agent dials out to the hub over a WebSocket, so no inbound port forwarding is needed.

Does Beszel support custom metrics on Proxmox?

No. As of v0.18.7 there are no arbitrary application-defined custom metrics and no PromQL-style query language, on Proxmox or anywhere else. You get the fixed metric set (CPU, memory, disk, disk I/O, network, load, temperature, GPU, battery, S.M.A.R.T., Docker stats). If you need custom application metrics from a Proxmox estate, pair Beszel with Prometheus and Grafana.

Do I still need Proxmox’s built-in graphs if I run Beszel?

Yes, for per-guest detail. Proxmox VE draws RRD graphs per node, VM and guest with hour-to-year views, which Beszel cannot reproduce. Beszel adds what Proxmox lacks: one view across machines that are not Proxmox, and threshold alerting on CPU, memory, disk, bandwidth, temperature and load. Proxmox’s notification system only covers events like failed backups, replication failures and fencing.

Related reading: