Pulse (rcourtman/Pulse): self-hosted monitoring for Proxmox, Docker, Kubernetes and TrueNAS

What Pulse is for, and the stack it replaces

Pulse is aimed at people who run a handful of platforms and do not want a separate monitoring product per platform. The README lists Proxmox VE, PBS and PMG, Docker and Podman, Kubernetes, TrueNAS SCALE and CORE, Linux, Windows and macOS machines, and early-access VMware vSphere. The pitch is that each platform keeps a dedicated view, while search, alerts, history and investigation sit on one shared resource model.

The second problem it targets is the gap between checks. A dashboard only shows what is true while someone is looking at it. Pulse Patrol runs scheduled checks over current state and recent history, and the README names the failures it is meant to catch: failed backups, capacity pressure, restart loops, unhealthy containers and clock drift.

This is not a metrics database with a query language. There is no PromQL surface described, and the retention numbers are edition-bound rather than configurable in the documentation. Treat it as an operations console for small to mid-sized fleets, not as a long-term time-series store.

How Pulse collects data: platform APIs first, agent second

The README is explicit that Proxmox VE, PBS and PMG are monitored through the Proxmox API with a read-only token, so nothing runs on the host, and the generated setup script creates a privilege-separated monitoring user. That is the default path, and it is the reason the Docker quick start does not mount the Docker socket: the server container does not need it.

The unified agent exists for data the platform API cannot give you. The README names host SMART health, temperatures, Docker hosts and standalone machines. The agent is described as operator-controlled: command execution is off by default, the local listener binds to localhost, and generated systemd units ship hardened. On Linux there is a --least-privilege profile that runs the service as a dedicated non-root user, with optional scoped sudo grants for collectors that need elevation.

The repository layout matches that split. The Go module github.com/rcourtman/pulse-go-rewrite depends on the Docker client libraries, k8s.io/client-go, gopsutil and modernc.org/sqlite, which is consistent with talking to several platform APIs and keeping local state in SQLite. cmd/, internal/ and pkg/ hold the Go side, frontend-modern/ holds the TypeScript UI, and deploy/ plus the Helm chart cover the cluster path.

One design choice is worth calling out. Patrol analysis is not purely local: the README says Community installations can use a local model or their own AI provider for watch-only analysis, and Pulse Pro adds investigation and policy-bound fixes with approval, verification and an audit trail. If your infrastructure data cannot leave your network, that is a constraint you have to check before enabling Patrol, not after.

Installing Pulse with Docker and reaching the setup screen

The quick start tells you to pick an exact version from the latest release and keep it pinned. The image tag is the placeholder rcourtman/pulse:vX.Y.Z, so substitute a real release tag rather than using latest.

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

After the container starts, open http://<your-ip>:7655 and follow the bootstrap-token setup. According to the README, Docker host monitoring comes from the unified agent, so the server container itself does not need the Docker socket mounted.

The Compose file in the repository shows the same shape with a few extras: the port mapping is ${PULSE_PORT:-7655}:7655, the volume is pulse-data:/data, TZ defaults to UTC, PULSE_DEPLOYMENT_METHOD is set to docker_compose, and a healthcheck polls http://localhost:7655/api/health every 30 seconds with a 10 second timeout and three retries.

services:
  pulse:
    image: ${PULSE_IMAGE:-rcourtman/pulse:6.4.3-rc.1}
    ports:
      - "${PULSE_PORT:-7655}:7655"
    volumes:
      - pulse-data:/data
    environment:
      - TZ=${TZ:-UTC}
      - PULSE_DEPLOYMENT_METHOD=docker_compose

For Proxmox LXC, plain Linux and Kubernetes the README points to docs/INSTALL.md and docs/KUBERNETES.md rather than inlining the steps. The Linux path uses a signed installer, and the README shows the verification before execution: download install.sh and install.sh.sshsig for the pinned version, verify the signature with ssh-keygen -Y verify against the pulse-installer key and the pulse-install namespace, then run bash install.sh --version "${PULSE_VERSION}".

export PULSE_VERSION=vX.Y.Z
curl -fsSLO "https://github.com/rcourtman/Pulse/releases/download/${PULSE_VERSION}/install.sh"
curl -fsSLO "https://github.com/rcourtman/Pulse/releases/download/${PULSE_VERSION}/install.sh.sshsig"
ssh-keygen -Y verify \
  -f <(printf '%s\n' 'pulse-installer namespaces="pulse-install" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMZd/DaH+BldzOkq1A8KVTcFk73nAyrE8aJOyf7i00jm pulse-installer') \
  -I pulse-installer \
  -n pulse-install \
  -s install.sh.sshsig < install.sh
bash install.sh --version "${PULSE_VERSION}"

That installer installs the server. Agents, including v5-to-v6 agent upgrades, are installed per host with the command generated under Settings, Infrastructure, Install on a host.

Where Pulse is the wrong tool

Retention is the first hard boundary. The README gives Community seven days of metric history, Relay fourteen days and Pro ninety days. If your incident review regularly reaches back a month, or you need to keep raw samples for capacity planning, none of those windows is a substitute for a time-series database, and the documentation does not describe a way to point Pulse at one.

vSphere is the second. The README calls it early-access and says to validate against your own vCenter before production use. That is the project's own wording, and it should be read literally: inventory, hosts, clusters, VMs, datastores, networks, snapshots and recovery context are listed, but the maturity claim is not there.

Edition gating is the third. Patrol investigation, governed fixes, RBAC, audit logging and reporting are Pro features, and centralized agent profiles are Pro as well. A Community install gets watch-only Patrol analysis. If the reason you are evaluating Pulse is automated remediation with an approval path, the free build does not include it.

The image source is a fourth trap. The README warns that GitHub release assets and the rcourtman/pulse images are Community builds, and that Relay, Pro and eligible legacy customers should use the private image or Linux archive from the Pulse download portal, because replacing a private Pro runtime with a public Community build removes its private runtime hooks. Pulling the public image onto a licensed host is a downgrade, not an upgrade.

Pulse compared with Prometheus and Grafana

The obvious alternative for this audience is Prometheus with node_exporter, cAdvisor and Grafana, plus Alertmanager for routing. The difference is in what each side has to be taught. Prometheus scrapes endpoints you configure and stores samples for as long as your retention flags allow; it knows nothing about a Proxmox guest, a PBS backup task or a TrueNAS replication job unless an exporter translates that into metrics. Pulse inverts this: the platform integrations are the product, and the shared resource model is what search, alerts and history run against.

That inversion has costs. You get the platforms the README lists and not an arbitrary scrape target, so a custom application exposing /metrics has no described path into Pulse. You also get the retention windows tied to editions instead of a retention flag. In exchange, Proxmox VE, PBS and PMG work through a read-only API token with no host agent, which is a shorter path to first data than writing or finding exporters for each platform.

If you already run Prometheus and Grafana and only need a nicer Proxmox view, adding Pulse means a second system with its own alert rules and its own history. If you have no monitoring at all and your estate is Proxmox plus Docker, Pulse gets you alerts and history without building a scrape topology first.

Maintenance, licensing and upgrade cost

The repository is not archived and the last push was on 2026-09-10, the same day as the v6.4.4-beta.2 release, so the project is being worked on. The release stream is worth reading before you pin anything: the recent entries are beta tags, v6.4.4-beta.1 and v6.4.4-beta.2, alongside a matching Helm chart release, helm-chart-6.4.4-beta.2. The quick start's instruction to pin an exact version matters more, not less, when the newest tags are betas.

Upgrade cost splits by install method. Docker and Compose upgrades are a tag change plus a container restart, with state in the pulse-data volume. The signed installer takes a --version argument, so Linux upgrades repeat the download and signature verification. Agents are upgraded separately, with the per-host command generated in the UI, and the README notes v5-to-v6 agent upgrades as a case the installer handles.

On licensing: the repository ships an MIT LICENSE file and the README states MIT. The editions above Community are commercial, and the README separates public Community artifacts from private Relay, Pro and MSP artifacts. Nothing here is legal advice, but the practical implication is that the licence of the code and the terms of the paid runtime are two different things, and the download portal is where the paid artifacts come from. TERMS.md sits at the repository root if you need to read the terms themselves.

Editorial conclusion

Adopt Pulse if you run Proxmox VE, PBS or PMG and want read-only API monitoring plus a Docker or Kubernetes view without standing up Prometheus, Grafana and Alertmanager. Skip it if you need long metric retention on a free build, or if you depend on vSphere in production, since the README labels that coverage early-access and tells you to validate against your own vCenter first. Before rolling it out, read docs/AGENT_SECURITY.md and confirm the privilege level of the unified agent on each host, and check which edition your build came from, because a public Community image replacing a private Pro runtime removes its private runtime hooks.

Frequently asked questions

Official sources

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