Pulse: a self-hosted monitoring workspace for Proxmox, Docker, Kubernetes and TrueNAS
Monitoring for Proxmox, Docker, Kubernetes, TrueNAS, and vSphere that watches your infrastructure for you: smart alerts, AI patrols that catch silent failures, and verified fixes
At a glance
- What is it?
- Pulse consolidates Proxmox, Docker, Kubernetes, TrueNAS, vSphere and bare machines into one Go server with a shared resource model, scheduled Patrol checks and edition-gated history. The design is deliberately operator-controlled, and the edition split is the first thing to understand before you install it.
- Who is it for?
- Adopt Pulse if you run Proxmox or TrueNAS at home or in a small lab and want one workspace instead of a Grafana and Prometheus stack. Do not adopt it if you need the Pro-tier Patrol investigation, governed fixes or ninety-day history, because the public GitHub images are Community builds and swapping one for a private Pro runtime strips its private runtime hooks.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Pulse targets: problems that appear between dashboard visits
A Grafana board answers the question you asked while looking at it. It does not answer the question you did not ask at 3am, which is whether last night's Proxmox backup actually completed or whether a container has been restarting in a loop since Tuesday. Pulse is built around that second question. The README states that it watches between visits, and lists the failure classes it looks for: failed backups, capacity pressure, restart loops, unhealthy containers and clock drift.
The intended audience is visible in the platform table. Proxmox VE, PBS and PMG get nodes, guests, storage, backups, replication, Ceph and mail gateways. Docker and Podman get hosts, containers, Compose projects, Swarm services, images and updates. TrueNAS SCALE and CORE get pools, datasets, disks, snapshots, replication tasks, apps and VMs. There is also Kubernetes coverage and an early-access vSphere integration. That list describes a homelab or a small managed-services estate far more than it describes a large enterprise, and the MSP edition, where one Pulse Account runs many isolated client runtimes, confirms the second reading.
What Pulse is not is a metrics database you query with PromQL. The README frames it as a workspace: platform pages keep storage and recovery information beside the infrastructure it belongs to, while Alerts, Actions and Patrol are cross-platform views. The unit of organisation is the resource, not the time series.
One resource model, several platform adapters, and an agent you often do not need
The architecture described in the README is a single server process that normalises several platform APIs into one shared resource model, then reuses that model for search, alerts, history and investigation. Proxmox, Docker, Kubernetes, TrueNAS, vSphere and standalone machines each get a dedicated view, but they are backed by the same underlying objects. That is why Alerts and Patrol can span platforms without per-platform configuration.
The agent question is answered unusually directly. For Proxmox VE, PBS and PMG, Pulse talks to the Proxmox API with a read-only token. Nothing runs on the host, and the generated setup script creates a privilege-separated monitoring user for you. The README is explicit that the Pulse server container does not need the Docker socket, because Docker host monitoring comes from the unified agent instead.
Install the agent only where the platform API cannot answer. The README names the cases: host SMART health, temperatures, Docker hosts, and standalone machines. That is a narrower agent footprint than most monitoring stacks of this scope, and it removes the usual argument about running privileged containers next to the workloads you are trying to observe.
Patrol is the second moving part. It runs scheduled checks across current state and recent history. On Community installations it can use a local model or your own AI provider, and the README scopes that to watch-only analysis. Investigation and policy-bound fixes, with approval, verification and an audit trail, are Pro features. There is also an interactive Assistant and an MCP adapter for external clients such as Claude Code and OpenCode, both sitting on the same inventory, metrics, alert, storage and governed-action contracts.
Getting it running: pinned versions, a signed installer, and a bootstrap token
The README is firm about pinning. Choose an exact version from the latest release and keep it pinned during installation. The Docker path is a single command:
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 that you open http://<your-ip>:7655 and follow the bootstrap-token setup. The environment variable PULSE_DEPLOYMENT_METHOD is set to docker_run in the example, which suggests the server adjusts behaviour based on how it was deployed, though the README does not enumerate the accepted values.
For Proxmox LXC, plain Linux and Kubernetes, the README points at docs/INSTALL.md and docs/KUBERNETES.md. The Linux and LXC installer is signed, and the README gives the verification sequence rather than just asserting that it is safe. You download install.sh and install.sh.sshsig for the pinned version, then run ssh-keygen -Y verify with the pulse-installer identity, the pulse-install namespace, and the embedded ed25519 public key, feeding install.sh on stdin. Only after a successful verification do you run bash install.sh --version "${PULSE_VERSION}" and delete both files.
The Helm chart is versioned alongside the application: the helm-chart-6.4.4-beta.2 release was published a minute after v6.4.4-beta.2. Agents, including v5-to-v6 upgrades, are installed with a per-host command generated under Settings, then Infrastructure, then Install on a host. There is no global agent installer script documented in the README.
The agent's privilege model is the most interesting design decision here
Most monitoring agents ask for root and are done with it. Pulse's README describes the opposite default. Command execution is off by default. The local listener binds to localhost. Generated systemd units ship hardened. On Linux, the installer's --least-privilege profile runs the service as a dedicated non-root user, with optional scoped sudo grants only for the collectors that need elevation.
The README points at docs/AGENT_SECURITY.md for what the agent can and cannot do at each privilege level. That document is not reproduced in the material available here, so the exact collector-to-privilege mapping cannot be confirmed from this source. What can be confirmed is the stated intent: the agent is operator-controlled by design, and elevation is opt-in per collector rather than assumed.
This matters because the agent is the component that touches SMART data, temperatures and Docker hosts, which are exactly the collectors that traditionally need broad host access. Pulse's answer is to make the grant explicit and narrow. Whether that is enough depends on the sudo rules the installer actually writes, and that is the first thing to read in AGENT_SECURITY.md before deploying at scale.
Credentials are encrypted at rest, API tokens are scoped, and governed fixes require the configured policy and approval path. Those are claims from the README's feature list rather than things this review can verify.
Community, Relay, Pro and MSP: the edition line runs through the middle of the product
The edition split is not cosmetic. Community gives self-hosted monitoring, seven days of metric history, core SSO, update alerts, and Patrol with your own provider or local model. Relay adds secure remote web access, Pulse Mobile pairing, push notifications, and fourteen days of history. Pro adds Patrol investigation, governed fixes, ninety days of history, centralized agent profiles, RBAC, audit logging and reporting. MSP runs one Pulse Account across many client workspaces, each with an isolated Pulse runtime, separate dashboards, alerts, users and audit history.
The README's licensing note is the part that catches people out. GitHub release assets and the rcourtman/pulse images are Community builds. Relay, Pro and eligible legacy customers are told to use the private image or Linux archive from the Pulse download portal, and the README warns that replacing a private Pro runtime with a public Community build removes its private runtime hooks.
So the practical consequence is that you cannot evaluate Pro by pulling from Docker Hub. You need portal access. The licence is MIT, which covers the source in the repository, but the README does not state which parts of the Pro runtime are in that source and which are not. Anyone planning to build from source should confirm that before committing. This is a factual gap in the available material, not a legal opinion.
History retention is the cleanest way to describe the tiers: seven, fourteen or ninety days, depending on edition. If your investigation habit is looking at last week, Community is enough. If it is looking at last quarter, it is not.
Where Pulse is the wrong tool, and what to use instead
The clearest limitation is vSphere. The README labels it early-access and says to validate against your own vCenter before production use. That is an honest label, and it should be read literally: if vSphere is your primary estate, Pulse is not yet the tool for it.
The second limitation is depth of metric analysis. Pulse stores history and surfaces alerts, but it is not a time-series query engine. If your workflow is writing PromQL expressions, building recording rules, or correlating high-cardinality labels across services, Prometheus plus Alertmanager plus Grafana is the better fit, and the difference is architectural rather than a matter of polish. Prometheus scrapes and stores raw series and leaves alerting logic to a separate rule language; Pulse normalises platform APIs into a resource model and applies its own alert logic and Patrol checks on top. The first gives you arbitrary queries over raw data. The second gives you curated answers about specific platforms. Neither substitutes for the other.
The third limitation is AI dependence. Patrol's watch-only analysis on Community runs against a local model or your own provider, which means you supply the model and absorb its cost and its failure modes. There is no documented fallback behaviour in the README for what happens when that provider is unreachable, so if Patrol is the reason you are evaluating Pulse, treat provider availability as part of your deployment plan.
Finally, the Pro-only governed fixes and investigation mean the feature the README leads with, verified fixes, is not in the build most people will install first.
Maintenance cost and what to check before you commit
The release cadence visible in the material is fast. v6.4.4-beta.1 landed on 2026-09-08 and v6.4.4-beta.2 on 2026-09-10, with the matching Helm chart published the same minute as the second beta. Betas are frequent, and the README's instruction to pin an exact version is a response to that. Pinning means you carry the upgrade decision yourself rather than tracking the tip.
The upgrade surface has three parts. The server, which the signed installer or the container image handles. The agents, which are upgraded with the per-host command under Settings, Infrastructure, Install on a host, and which the README explicitly says covers v5-to-v6 agent upgrades. And the Helm chart, which carries its own version number that may not match the application version. A chart upgrade and an application upgrade are two separate operations, and the release list shows they are published independently.
Before installing, verify two things that the README leaves open. First, read docs/AGENT_SECURITY.md and confirm the sudo grants the --least-privilege profile writes are ones you accept. Second, if you intend to use Relay, Pro or MSP, confirm portal access before you start, because the public images will not give you those runtimes and the README warns that swapping a private Pro runtime for a Community build removes its private runtime hooks. Community users on Proxmox with a read-only API token can skip the agent entirely and have the smallest footprint of any configuration described here.
Editorial conclusion
Adopt Pulse if you run Proxmox or TrueNAS at home or in a small lab and want one workspace instead of a Grafana and Prometheus stack. Do not adopt it if you need the Pro-tier Patrol investigation, governed fixes or ninety-day history, because the public GitHub images are Community builds and swapping one for a private Pro runtime strips its private runtime hooks. Before installing, verify the signed install.sh against the pinned pulse-installer key, and check the edition table against what you actually need.
Community notes