Pulse for Proxmox: Set Up Monitoring in 15 Minutes

Built a Proxmox cluster. Three nodes, a dozen VMs, backups on PBS. And zero visibility: you find out what’s happening inside only when users start saying “everything’s down.” Sound familiar? Proxmox monitoring through Pulse closes that gap with one command in the terminal. No Zabbix, no agents on every node, no week of setup.

This article is written as a working recipe, not a feature overview copied from the vendor’s site. We’ll cover three installation methods, setting up a safe read-only token, wiring up alerts, and the real errors people hit on first run, including the infamous 401 that fills half the project’s GitHub issue tracker.

1. Diagnosis: why Proxmox’s built-in tools aren’t enough

The Proxmox web UI shows the state of the node you’re currently logged into. Want to see the whole cluster? Open five tabs. Want to know if a PBS backup has failed for the third night in a row? Go dig through logs manually. No alerts out of the box, no metric history beyond a day, no single screen for all nodes.

The built-in RRD graph in Proxmox stores one-minute data points only for the last hour, then it starts averaging. A single spike at 3 AM simply won’t show up on a weekly graph. And it’s exactly those night-time spikes that take production down: someone changes something during the day, it blows up at night, and you’re left guessing who’s to blame from memory.

There’s a behavioral pattern here that matters beyond SEO, it applies to real operations too: the later you find out about a problem, the more expensive it is to fix. A Telegram alert 20 minutes before a disk fails completely is a planned replacement. The same disk found after the fact, through user complaints, means restoring from backup and explaining yourself to management.

Real case: a three-node cluster, where a ZFS pool on one node silently went DEGRADED for almost a week. Nobody checked, why would they, everything still worked. It worked right up until the second disk in the mirror dropped out, and then it stopped working abruptly and completely. Five minutes spent setting up a pool status alert would have saved a full day of restoring from backup. Stories like this are exactly why monitoring gets installed right after the hypervisor, not “whenever there’s time.”

Coming up in this article:

• what Pulse can do and how it differs from Zabbix and Checkmk
• three installation methods: LXC script, Docker, manual install.sh
• setting up a monitoring user and API token in Proxmox with minimal privileges
• connecting alerts and push mode for an isolated PBS
• breaking down real 401/403 errors when connecting a token
• what to add for monitoring Docker and Kubernetes alongside Proxmox

Setup time: 15 minutes. Full configuration with alerts and config backup: an hour, if you don’t get distracted. Pour yourself some coffee anyway, this is a long one.

2. Why pick Pulse instead of building out Zabbix for three nodes

One nuance. Pulse is a solo project by one developer (Richard Courtman), MIT licensed, with a free self-hosted tier that’s fully functional for basic monitoring. The paid Pulse Pro adds AI patrols and auto-fixes, which you don’t really need for a home cluster or small production setup.

From real user numbers: a Pulse instance in an LXC with 2 cores monitoring fifty devices sits at single-digit CPU percentage idle, with noticeable load only when many people have the dashboard open at once across different browsers. For comparison, a Zabbix server with a database behind it, monitoring the same number of hosts, usually needs a dedicated VM with 2+ GB RAM just for the server itself, not counting agents.

How it works under the hood

The backend is written in Go, the frontend in SolidJS. This isn’t just trivia: this combination gives low memory usage and fast container cold start, seconds, not tens of seconds like a Java-based stack. Each Proxmox node is polled in its own goroutine through the standard REST API, without blocking each other: if the connection to one node drops, the rest keep getting polled normally.

For Docker, Kubernetes, and TrueNAS, version 6 added a separate mechanism: lightweight agents send metrics to Pulse via POST request on their own, instead of waiting to be polled. Proxmox doesn’t need this: the standard API is enough, no agent required on the hypervisor at all.

Comparison with the closest competitors

“Quite the appetite you’ve got there,” the Zabbix database would say if you tried spinning it up just to monitor three nodes in a home lab. For that scale, it’s massive overkill.

The decision is simple. Three to fifteen nodes, pure Proxmox ecosystem, want results in an evening: Pulse. Mixed infrastructure with network gear, printers, and servers on other hypervisors all thrown together: a universal tool like Zabbix or Checkmk will earn its setup time and cost.

3. Recipe: deploying Pulse and connecting Proxmox

3.1. What you need before starting

As of publication, the current version is Pulse v6.1.2. Before installing, check the latest releases on the GitHub page, the project updates often, and v6 added unified monitoring for Docker, Kubernetes, and TrueNAS in one window.

Port reference table

3.2. Method A: LXC container (the fastest)

If you already have a Proxmox host and don’t want to spin up a separate VM, just run this from the Proxmox console. The script from community-scripts creates an LXC, installs Pulse, and tells you the next step right away.

bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/pulse.sh)"

Result: a new LXC container running Pulse on port 7655. The script asks about disk, RAM, and CPU; for monitoring 3-10 nodes, 1 vCPU and 512 MB RAM is enough.

3.3. Method B: Docker (if you already have a Docker host)

The official image is rcourtman/pulse, no other forks.

docker run -d \
  --name pulse \
  -p 7655:7655 \
  -v pulse_data:/data \
  --restart unless-stopped \
  rcourtman/pulse:latest

Want to set the login and password right away without the initial setup screen? Add environment variables:

docker run -d \
  --name pulse \
  -p 7655:7655 \
  -v pulse_data:/data \
  -e PULSE_AUTH_USER="admin" \
  -e PULSE_AUTH_PASS="StrongPassword123" \
  --restart unless-stopped \
  rcourtman/pulse:latest

Result: container is up, docker ps shows status Up, port 7655 is listening.

If you prefer Docker Compose, don’t retype the command by hand every time you update, keep the config in a file:

services:
  pulse:
    image: rcourtman/pulse:latest
    container_name: pulse
    restart: unless-stopped
    ports:
      - "7655:7655"
    volumes:
      - pulse_data:/data
    environment:
      - PULSE_AUTH_USER=admin
      - PULSE_AUTH_PASS=StrongPassword123

volumes:
  pulse_data:

docker compose up -d

Result: same single line in the logs at startup, but now updating is docker compose pull && docker compose up -d, no need to retype flags manually.

3.4. Method C: manual install (for an existing VM/LXC)

curl -fsSL https://raw.githubusercontent.com/rcourtman/Pulse/main/install.sh | sudo bash

The script detects your system, installs a systemd unit, and starts the service. Then open http://server-IP:7655 in your browser, you’ll see the initial setup wizard.

Pick this method if you already have a dedicated VM or LXC for utility services and don’t want to drag in Docker just for one container. The downside: updates need to be run manually via the same install.sh, Docker is somewhat more convenient here for a CI/CD-style update approach.

Which of the three methods should you pick? If you only have one Proxmox host and need monitoring right now, go with the LXC script from Method A. If you already have a Docker host running other services, go with Method B, drop it into your existing Compose file. Method C is for people who don’t like containers on principle and run everything as bare systemd units.

3.5. Creating a dedicated monitoring user in Proxmox

Don’t be lazy here. A root token with full access is convenient right up until your first config leak incident. Create a separate read-only user.

# User in realm pve (not pam, to avoid creating system users)
pveum user add pulse-monitor@pve --comment "Read-only monitoring for Pulse"

# Role based on PVEAuditor, Pulse only needs read access
pveum aclmod / -user pulse-monitor@pve -role PVEAuditor

# Token WITHOUT privilege separation, otherwise the token gets empty permissions
pveum user token add pulse-monitor@pve pulse-token --privsep 0

The output of the last command includes a value field, that’s your token secret. Copy it immediately, Proxmox won’t show it again.

Why PVEAuditor specifically, and not something broader? The role gives read access to everything monitoring needs: node, VM, container, and storage statuses, and backup job status. It has zero permission to start, stop, or change configuration, even if the token leaks, the worst an attacker gets is a list of your infrastructure, not a lever to break it. For monitoring, that’s exactly the minimum privilege needed, no more.

3.6. Connecting a Proxmox node in the Pulse web interface

Open Pulse → Settings → Add Node → Proxmox VE and fill in the fields: the host address with port 8006, the username in the format pulse-monitor@pve!pulse-token, and the token value. Separately: if the nodes are in a cluster, Pulse will auto-discover the rest after connecting the first one.

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'lineColor': '#64748b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'flowchart': {'curve': 'linear', 'nodeSpacing': 50, 'rankSpacing': 50}
}}%%
flowchart TD
    A["Proxmox VE node"] --> B["API port 8006"]
    C["Proxmox Backup Server"] --> D["API port 8007"]
    B --> E["Pulse server"]
    D --> E
    E --> F["Web dashboard 7655"]
    E --> G["Alerts Telegram Discord Email"]
    style A fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style C fill:#f8fafc,stroke:#3b82f6,stroke-width:2px,color:#1e40af
    style E fill:#f8fafc,stroke:#22c55e,stroke-width:2px,color:#15803d
    style G fill:#f8fafc,stroke:#f97316,stroke-width:2px,color:#c2410c

For an isolated PBS with no inbound connections, there’s push mode: PBS sends metrics to Pulse on a schedule, no inbound access to port 8007 needed at all. Configured with a separate key in the PBS → Push Mode section of the project docs.

Here’s what the polling cycle looks like at the protocol level, worth keeping in mind when you’re digging through logs and can’t figure out where a dashboard delay is coming from:

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#f8fafc',
    'primaryTextColor': '#1e293b',
    'primaryBorderColor': '#94a3b8',
    'noteBkgColor': '#fefce8',
    'noteTextColor': '#713f12',
    'noteBorderColor': '#fbbf24',
    'actorBkg': '#f8fafc',
    'actorBorder': '#94a3b8',
    'actorTextColor': '#1e293b',
    'fontSize': '15px',
    'fontFamily': 'ui-sans-serif, system-ui, sans-serif'
  },
  'sequence': {
    'mirrorActors': false,
    'messageAlign': 'center',
    'actorMargin': 120,
    'width': 160,
    'noteMargin': 12
  }
}}%%
sequenceDiagram
    participant U as Browser
    participant P as Pulse server
    participant N as Proxmox node
    U->>P: Opened dashboard
    P->>N: Request via API token
    N->>P: JSON with status and metrics
    P->>U: Chart update
    Note over P,N: Polling stops with no open tabs

What appears on the dashboard after connecting

Right after the first successful poll, the Pulse home screen shows cards for each node: CPU load, RAM usage, disk status, and already mounted storage. A separate tab combines all VMs and LXC containers in the cluster into one list, filterable by status (running, stopped, paused) and by the node they’re running on.

The Storage tab shows not just fill percentage but also storage type (ZFS, LVM-thin, directory), with a dedicated indicator for ZFS pools: ONLINE, DEGRADED, FAULTED. This is exactly the indicator that would have prevented the week-long DEGRADED story from the diagnosis section above.

The Backups tab pulls jobs from PBS or the built-in vzdump and shows the time of the last successful run for each VM individually. If a specific machine’s backup hasn’t run successfully past a set threshold, the card gets highlighted, and that’s exactly where you configure an alert from the notifications section below.

3.7. HTTPS via reverse proxy

Pulse’s built-in web interface serves HTTP on 7655. If you plan to access it from outside the local network, put nginx with a certificate in front, don’t expose 7655 directly.

server {
    listen 443 ssl;
    server_name pulse.example.local;

    ssl_certificate     /etc/letsencrypt/live/pulse.example.local/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pulse.example.local/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:7655;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

The Upgrade and Connection headers are mandatory: the Pulse dashboard holds a websocket for live metric updates, without them the charts freeze and only update on F5.

3.8. Tuning the polling interval and history retention

By default, Pulse polls nodes every few seconds as long as at least one dashboard client is open. For three to five nodes this doesn’t matter. For a cluster of 20+ nodes with hundreds of VMs, it makes sense to increase the interval and limit history depth, otherwise the disk under /data will grow faster than you can set up rotation.

# Settings -> General -> Polling & Storage
polling_interval_seconds: 15
metrics_retention_days: 30

Result: less load on the Proxmox API from constant requests, the dashboard updates slightly less often, but the server running Pulse doesn’t run out of disk space after a month of use. The balance is simple: the bigger the cluster, the longer the interval. Second-level precision matters on five nodes, not fifty.

3.9. Setting up alerts

Settings → Notifications → add a channel. Telegram, Discord, Slack, email, and webhooks are all supported. CPU/RAM/disk thresholds are set as percentages, backup thresholds are set as hours since the last successful job.

# Example alert configuration in Pulse (Settings -> Alerts)
threshold_cpu_percent: 90
threshold_memory_percent: 85
threshold_disk_percent: 90
backup_stale_hours: 26
notify_channels: [telegram, email]

4. Verification: confirming monitoring actually works

# Service status for manual install
systemctl status pulse

# Container status for Docker install
docker ps --filter name=pulse

# Logs, if something's wrong
docker logs -f pulse
# or
journalctl -u pulse -f

# Check that the Proxmox API responds to the token
curl -k -H "Authorization: PVEAPIToken=pulse-monitor@pve!pulse-token=YOUR-SECRET" \
  https://node-IP:8006/api2/json/nodes

If the last command returned JSON with a list of nodes, not an error, the token works, and any remaining problem is on the Pulse side, not Proxmox. Open the dashboard, the node should appear in the list within 10-30 seconds of the first poll.

5. Complications: breaking down real errors

Recovering from a failure

If the host running Pulse dies completely, spin up a new container or LXC of the same version, restore the /data volume/directory from backup, and start the service. Node settings, tokens, and alert history come back automatically, you won’t need to re-enter Proxmox tokens.

# Restoring a volume from archive for a Docker install
docker volume create pulse_data
docker run --rm -v pulse_data:/data -v $(pwd):/backup alpine \
  tar xzf /backup/pulse-backup-2026-07-30.tar.gz -C /data
docker compose up -d

A backup that’s never been restored isn’t a backup, it’s a nice-looking file on disk that you simply trust exists. Once a quarter, spin up a test container on a separate port and restore the archive into it, confirming the restore actually works instead of just piling up in storage for years untested.

For a home lab, there’s a separate installation option: a Home Assistant add-on. If you already run Home Assistant alongside Proxmox, Pulse Server and Pulse Agent can run as its add-ons, no separate VM or LXC needed for monitoring. For production, I don’t recommend this: add-on isolation and updates in Home Assistant aren’t as strict as a dedicated service.

It’s not as bad as this table makes it look. In practice, 90% of problems come down to token privsep. One flag fixes almost everything.

6. Alternatives: when Pulse isn’t the right call

• Zabbix: harder to set up, but monitors literally everything in your infrastructure, not just Proxmox. Pick it if you already have a Zabbix server running and need to add a couple nodes, rather than deploying a separate stack.
• Checkmk: similar story, overkill for three nodes, but strong if you need unified monitoring across hundreds of hosts mixed in with network gear.
• Grafana + Prometheus + pve-exporter: more flexible for visualization and history storage, but assembling a three-component stack just for nice graphs only makes sense if Grafana is already running for other purposes.
• Proxmox Datacenter Manager (PDM): the official tool from Proxmox itself for managing multiple clusters. Good as a web UI replacement, and can remotely manage nodes across different clusters from one place, but it has fewer alerts and shallower metrics than Pulse right now. Think of it more as a control panel than an observability system.
• Netdata: if you want to monitor more than just Proxmox, down to deep OS-level metrics on every node: context switches, interrupts, detailed per-process breakdown. But that’s an agent on every host, not read-only API access, and you’ll have to install it on every node individually, including the hypervisor.

Nothing stops you from combining tools: Pulse as a quick overview dashboard and alert source for Proxmox infrastructure, with Zabbix or Grafana as the company-wide monitoring hub, with Pulse optionally forwarding metrics there via webhook. This is common when monitoring was already built around other systems and Proxmox got added to the infrastructure later.

If the cluster is small and the Proxmox API is your only data source, Pulse wins on time-invested-versus-value-gained. For an enterprise with a hundred hosts of mixed types, look at Zabbix or Checkmk.

A separate note on the built-in Proxmox Backup Server. It can send notifications about failed jobs on its own, but only about itself, and only via email. If you need a single screen showing node, VM, and backup status all at once, PBS’s built-in emails aren’t enough, you’ll still need a separate dashboard.

Pulse free tier versus Pulse Pro

For a home lab or small production setup, the free tier is more than enough. Pro makes sense where monitoring becomes a dedicated job with an SLA and you need automatic incident analysis without a human in the loop.

7. Prevention: so you don’t fix this at 3 AM

Monitoring Pulse itself

Yes, the thing doing the monitoring needs its own monitoring. Add a Pulse check via cron or an external uptime service: ping port 7655 every 5 minutes.

# Simple availability check, drop this in cron
curl -sf http://127.0.0.1:7655/api/health || echo "Pulse is down" | mail -s "ALERT: Pulse down" you@your-mail.com

Config backup

# Backing up the volume for a Docker install
docker run --rm -v pulse_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/pulse-backup-$(date +%F).tar.gz -C /data .

Autostart

With Docker, the --restart unless-stopped flag already in the install command above is enough. For a manual install via install.sh, confirm the unit is enabled:

systemctl enable pulse
systemctl is-enabled pulse

Security

Monitoring itself is an attractive attack target: it sees your whole infrastructure at once, and its token potentially opens read access to the entire cluster. Treat the Pulse host with the same seriousness as the hypervisors themselves.

• UFW: open 7655 only for a trusted subnet, don’t expose it externally without a VPN or an authenticated reverse proxy
• fail2ban: if the web interface is exposed externally anyway, set up a jail on the login form so password brute-forcing hits an IP ban after a few attempts
• SSH hardening on the Pulse host: disable password login, keep keys only, change the port if that’s your only defense against automated scanners
• A dedicated read-only user in Proxmox for each monitoring source, never a root token: the PVEAuditor role physically can’t break anything, even if the token leaks
• Backups of tokens and config stored outside the Pulse host itself, otherwise one incident takes out both your data and your way of recovering it
• IP restriction at the Proxmox firewall level for port 8006, if Pulse has a static address: an extra barrier even if a valid token leaks

# Example UFW rule: allow 7655 only from the local subnet
ufw allow from 192.168.1.0/24 to any port 7655 proto tcp
ufw deny 7655

A small leak sinks a big ship. One monitoring dashboard exposed externally without a password puts the whole company’s perimeter at risk.

Updating

# Docker
docker pull rcourtman/pulse:latest
docker stop pulse && docker rm pulse
# then repeat docker run with the same volume and variables

# Manual install / LXC
curl -fsSL https://raw.githubusercontent.com/rcourtman/Pulse/main/install.sh | bash

Before updating: back up the volume/data as described above. To roll back on failure: for Docker, spin up a container with the old version tag from Releases; for a manual install, reinstall a specific version with the --version flag on install.sh.

8. FAQ

Why won’t Pulse connect to Proxmox after setup?

Nine times out of ten it’s the token: either privilege separation is enabled and the token has empty permissions, or the role is assigned somewhere other than the root path /. Check both with pveum acl list and recreate the token with –privsep 0.

How do I verify that Proxmox monitoring through Pulse is working correctly?

Open the Pulse dashboard, the node should show current CPU, RAM, and status from the last 30 seconds. Additionally, check with a manual curl request to the Proxmox API using the same token, if JSON comes back, the issue isn’t permissions, it’s Pulse itself.

What do I do if Pulse is loading CPU on a weak server?

Increase the polling interval in settings, close extra open dashboard tabs. Pulse lowers polling frequency when there are no active clients, but with tabs constantly open across multiple browsers, load grows proportionally.

How is Pulse different from Zabbix for Proxmox monitoring?

Pulse is built specifically for the Proxmox ecosystem: it understands Ceph, ZFS, and PBS backup status out of the box, and deploys with one command. Zabbix is more universal and monitors any infrastructure, but needs a dedicated server, a database, and significantly more setup from scratch.

Can one Pulse instance monitor multiple Proxmox clusters?

Yes, add nodes from each cluster separately through Settings → Add Node, each independent cluster gets its own token. Within a single cluster, connecting one node is enough, Pulse discovers the rest automatically through cluster membership.

Does Pulse need an agent on Proxmox nodes?

No, monitoring Proxmox VE and PBS itself doesn’t require an agent, Pulse communicates through the standard REST API using a token. Agents are only needed if you’re additionally connecting Docker hosts, Kubernetes, or want to pull SMART/temperature data from inside guest systems.

Can I use Pulse for free in a commercial project?

Yes, the self-hosted version is distributed under the MIT license and is fully functional for basic monitoring with no node count limits. Paid Pulse Pro is a separate layer of AI features and extended analytics, not a requirement for commercial use of the base version.

How do I migrate Pulse settings to a new server?

Back up the /data directory (or Docker volume pulse_data) as described in the prevention section, deploy the same version of Pulse on the new host, extract the archive into the volume, and start the service. Node tokens and alert config come back automatically, nothing needs re-entering.

How often does Pulse get updated, and do I need to update immediately?

The project is actively developed, patch releases come out every few weeks. You don’t need to update the day of release, but checking the changelog every month or two is worth it, that’s where they fix things like excessive syslog spam on nodes and clarify API token behavior, discussed in the errors section.

8.1. A note on Proxmox Mail Gateway

If your infrastructure also runs PMG, Pulse connects to it the same way as PVE: a read-only user, a token without privilege separation, adding the node through the same wizard in Settings. PMG shows up on the dashboard as a separate tab with mail queue, spam filter stats, and service status, no need to set up a separate monitoring tool just because it’s a mail gateway rather than a hypervisor.

9. Outlook

After setup, you have a live dashboard across all Proxmox nodes, Telegram alerts when a backup fails or a disk fills up, and metric history instead of one-off snapshots. No more opening five web UI tabs just to understand what’s happening across the whole cluster.

From here it’s just a matter of maintenance: connect PBS through push mode if it’s isolated, tune thresholds to your workload, and don’t forget to back up the config before every update. The cluster grows from three nodes to thirty, Pulse stays the same, only the polling interval and history depth change, no architecture rework needed.

If there’s a Docker host or Kubernetes cluster running alongside Proxmox, don’t build a separate monitoring system for every infrastructure type, version 6 brings it all into one dashboard. Fewer browser tabs means less chance of missing an alert buried among cat picture tabs.

Born in a home lab, ready for production. Tested on clusters from three nodes in a garage to fifty on rented racks: the recipe in this article is the same, the only difference is the polling interval and how much coffee you drink during setup. If something doesn’t come up, leave a comment, we’ll figure it out.