Pulse: Proxmox, Docker and Kubernetes in one Go binary, with an agent you may not need

Platform APIs first, agents only where the API cannot see

The design decision that shapes everything else is that an agent is optional. Proxmox VE, PBS and PMG are monitored through the Proxmox API with a read-only token, so nothing runs on the host at all, and the generated setup script creates a privilege-separated monitoring user.

Install the unified agent only where you want data the platform API cannot give you: host SMART health, temperatures, Docker hosts, or standalone Linux, Windows and macOS machines. The coverage table shows the split clearly. Proxmox brings nodes, guests, storage, backups, replication, Ceph and mail gateways. Docker and Podman bring hosts, containers, Compose projects, Swarm services, health, images and updates. TrueNAS covers pools, datasets, disks, snapshots and replication tasks. Kubernetes, like Docker and Podman hosts, comes through the same unified agent, so those platforms do require something on the host.

The installer is verified with an SSH signature or it does not run

The install path is unusually careful, and the care is in the mechanics rather than in prose. You set PULSE_VERSION to an exact tag, download install.sh and its .sshsig alongside it, then verify with ssh-keygen -Y verify against an inline ed25519 public key with namespaces set to pulse-install, before running the script.

The README is explicit about the failure contract: paste the whole block, and installation stops if either download or signature verification fails. It also tells you not to run the final command separately to work around a failure, which is the part that matters, because that is exactly the habit that makes signature checks theatre.

The pinned key is written into the command itself, so the verification does not depend on a key you fetched separately. That is a defensible design for a small project: the trust anchor ships in the instruction, and the tag in the URL is the trust root.

A single docker run, one volume, and no Docker socket

The Docker path is the shortest route to a running instance. The command runs the image detached, publishes port 7655, mounts a named volume at /data, sets PULSE_DEPLOYMENT_METHOD to docker_run, and restarts unless stopped.

docker run -d \
  --name pulse \
  -p 7655:7655 \
  -v pulse_data:/data \
  -e PULSE_DEPLOYMENT_METHOD=docker_run \
  --restart unless-stopped \
  rcourtman/pulse:vX.Y.Z

The version is a placeholder you replace with a pinned tag, and the README asks you to keep that version pinned during installation.

The detail worth noticing is what is absent. The server container does not need the Docker socket, because Docker host monitoring is handled by the unified agent instead. A monitoring tool that mounts the Docker socket is effectively root on the host, so the design choice here removes that entire class of risk rather than documenting around it.

Agent command execution is off, the listener is localhost, units are hardened

Command execution is disabled by default. The local listener binds to localhost. On Linux the installer's --least-privilege profile runs the service as a dedicated non-root user.

A separate agent security model document describes exactly what the agent can and cannot do at each privilege level, which is the right place to look before deciding how much to trust it. The README also says credentials are encrypted at rest.

Agents are installed and upgraded, including v5 to v6 upgrades, through a per-host command generated in the settings area rather than by hand. That is a deliberate difference from the server installer, which comes from GitHub releases.

Community gets seven days of history; Pro is where the fixes live

The edition split is not cosmetic and it is worth reading before you deploy. Community is self-hosted monitoring with seven days of metric history, core SSO, update alerts, and Patrol running on your own provider or a local model. Pro adds Patrol investigation, governed fixes, ninety days of history, centralized agent profiles, RBAC, audit logging and reporting.

Patrol runs scheduled checks for problems a dashboard only shows if someone is looking. Patrol investigation and fixes are the paid part.

That boundary is the commercial decision inside the product: the free edition tells you what is wrong, the paid one acts. There is also an MSP tier where one account runs many client workspaces, each with separate dashboards, alerts, users, audit history and reports, plus a free sixty-day two-client evaluation.

vSphere is labelled early access, and Community images are not Pro images

One warning in the README deserves to be quoted rather than paraphrased.

The platform coverage table describes VMware vSphere support as early access, covering hosts, clusters, VMs, datastores, networks and snapshots, and tells you to validate it against your own vCenter before relying on it. That is the project saying its own coverage is provisional, and it is the only platform in that table with that caveat.

Relay is gone, and the Go build targets 1.26 with SQLite

On the build side, the Go module requires go 1.26.0 with toolchain go1.26.10, and the backend stage of the container build pins golang 1.26.10-alpine by digest. Storage is modernc.org/sqlite rather than a database server, which is why the compose file mounts a single pulse-data volume and nothing else. The frontend is built first from frontend-modern on node 24-alpine because it is embedded into the binary afterwards, and shipped images build with a release tag that fails closed on mock fixtures, admin bypass and licensing environment overrides.

Releases are tagged in pairs, a version and a matching Helm chart version, currently at 6.7.0.

Editorial conclusion

Pulse fits a homelab or small MSP running mixed Proxmox, Docker and Kubernetes estates that wants one place to see alerts, history and recovery context without assembling a Prometheus plus Grafana plus alerting stack. It does not fit a team that needs SSO beyond the core edition, role-based access control, audit logging, more than seven days of history, or governed automated fixes, because those are Pro. Before committing, check three things: whether the vSphere coverage holds up against your own vCenter, since the README says to validate it; whether seven days of metric history is enough on Community; and whether you are willing to run the Patrol analysis through your own provider or a local model.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. rcourtman/Pulse on GitHub
4. README
5. Releases