The vSphere adapter filled `Resource.Tags` with six fixed strings on every resource — `vmware`, `vsphere`, `<kind>`, `source:vcenter`, `connection:<name>`, `power:<state>` — and never read vCenter's own tag and category system. Every VM in an estate returned a byte-identical set, so the workload Tags column rendered the same dots on every row and filtering on any of them selected everything. Commit6b78feba8default-hid the column and said in as many words that the hide was a stopgap awaiting this fix. `internal/vmware/client_tags.go` reads the CIS tagging service. That is a different endpoint family from the `/api/vcenter/...` inventory reads, but the same vSphere Automation API, so it reuses the caller's `/api/session` token rather than opening and managing a second session. Associations come from one batched `list-attached-tags-on-objects` POST per bounded object batch, never a per-object request; tag and category names resolve through a client-scoped catalog with a 10-minute TTL, so a steady-state refresh of a tagged estate costs only the association reads while a rename still converges without a restart. A vCenter without the tagging service, or an account without the tag read privilege, degrades into a `tags` stage enrichment issue and leaves the inventory untagged; it never fails the refresh. The provenance strings stay. `Resource.Tags` is the only keyword set `resourceSearchMatch.ts`, the `?tags=` resources filter, and saved report-schedule tag filters read — `collectSearchCandidates` gathers no `technology`, `type`, or `platformScopes` candidate — so dropping "vmware" or "vsphere" would silently stop matching searches and saved filters that depend on them. Real vCenter labels are appended to that set, never substituted for it. Because that flat set is deliberately mixed, it is the wrong source for a per-row Tags cell. Real tags therefore also land on a canonical `VMware.Tags` facet that carries vCenter's category alongside each name, and `useWorkloads.ts` maps `WorkloadGuest.tags` from that facet for any resource carrying VMware metadata — including the empty case, so a vSphere VM nobody tagged renders an empty cell instead of falling back to the provenance dots. vCenter tag names are unique only inside their category, so the flat label is `category:name`: two categories may each hold a "Production". With the column carrying per-row meaning again, `tags` leaves VMWARE_WORKLOAD_DEFAULT_HIDDEN_COLUMN_IDS and the `defaultHiddenMigrationIds` retirement list, and the state-model test that pinned the stopgap now pins its absence. No un-hide migration ships alongside it:6b78feba8is on main but no tag contains it, so the stopgap never shipped and no install carries the auto-hidden preference. That holds only while the two stay together — the migration writes the hide into each user's saved preference on first load, so an rc cut from main carrying the stopgap without this commit would make an explicit un-hide path necessary. Mock fixtures carry uneven tag coverage — several categories on some objects, one on others, none on the rest — because a uniform fixture set would hide exactly the defect this data exists to catch. Verified against a mock estate built from this branch: `/api/resources` returns provenance plus real labels on the flat set and only real labels on `vmware.tags`; the Tags column renders 2-4 dots per tagged VM and none for untagged ones; a dot's tooltip reads `Backup:Nightly`, and clicking it searches `tags:Backup:Nightly` and narrows 18 VMs to the 3 that carry it. Contract deltas: performance-and-scalability.md Extension Point 17 replaces the stopgap paragraph with the two-surface tag contract and the bounded tag-read budget; unified-resources.md states the keyword-union vs facet split and that a present-but-empty facet means "no operator tags" rather than a fallback; storage-recovery.md extends its VMware descriptive-only boundary to `vmware.tags`, because vCenter tag vocabularies read like protection policy (`Backup:Nightly`) and a label the operator wrote must never satisfy a coverage or compliance verdict that recovery-owned evidence should decide.
Pulse
Pulse is a self-hosted monitoring workspace for Proxmox, Docker, Kubernetes, TrueNAS, physical and virtual machines, and early-access VMware vSphere environments. It combines live infrastructure state, history, alerts, recovery visibility, and scheduled health checks without requiring a conventional enterprise monitoring stack.
Why Pulse
- It watches between visits. Alerts and Pulse Patrol find failed backups, capacity pressure, restart loops, unhealthy containers, clock drift, and other problems that dashboards cannot surface when nobody is looking.
- It keeps each platform familiar. Proxmox, Docker, Kubernetes, TrueNAS, vSphere, and machines have dedicated views, backed by one shared resource model for search, alerts, history, and investigation.
- It stays operator-controlled. Credentials are encrypted at rest, API tokens are scoped, agent commands are disabled by default, and governed fixes require the configured policy and approval path.
Platform coverage
| Platform | Coverage |
|---|---|
| Proxmox VE, PBS, and PMG | Nodes, guests, storage, backups, replication, Ceph, mail gateways, and alerts |
| Docker and Podman | Hosts, containers, Compose projects, Swarm services, health, images, and updates |
| Kubernetes | Clusters, nodes, workloads, pods, services, storage, and events through the unified agent |
| TrueNAS SCALE and CORE | Pools, datasets, disks, snapshots, replication tasks, apps, VMs, and alerts |
| Linux, Windows, and macOS machines | Host health, filesystems, networking, temperatures, RAID, and availability through the unified agent |
| VMware vSphere | Early-access inventory, hosts, clusters, VMs, datastores, networks, snapshots, and recovery context; validate against your own vCenter before production use |
Platform pages keep storage and recovery information beside the infrastructure it belongs to. Alerts, Actions, and Patrol remain cross-platform views.
Patrol: monitoring that does rounds
Pulse Patrol runs scheduled checks across the current state and recent history of your infrastructure. Community installations can use a local model or their own AI provider for watch-only analysis. Pulse Pro adds investigation and policy-bound fixes with approval, verification, and an audit trail.
Pulse also includes an interactive Assistant and an MCP adapter for external clients such as Claude Code and OpenCode. Both sit on top of the same scoped inventory, metrics, alert, storage, and governed-action contracts.
Quick start
Choose an exact version from the latest release and keep that version pinned during installation.
Docker
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
Open http://<your-ip>:7655 and follow the bootstrap-token setup. Docker host
monitoring is provided by the unified agent; the Pulse server container does
not need the Docker socket.
Proxmox LXC, Linux, and Kubernetes
The installer is signed. Verify install.sh against the pinned
pulse-installer key before running it:
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}"
rm -f install.sh install.sh.sshsig
The GitHub installer installs the Pulse server. Install and upgrade agents with the per-host command generated under Settings → Infrastructure → Install on a host.
Important
GitHub release assets and
rcourtman/pulseimages are Community builds. Relay, Pro, and eligible legacy customers should use the private image or Linux archive provided by the Pulse download portal. Replacing a private Pro runtime with a public Community build removes its private runtime hooks.
Editions
- Community — self-hosted monitoring, seven days of metric history, core SSO, update alerts, and Patrol with your own provider or local model.
- Relay — Community plus secure remote web access, Pulse Mobile pairing, push notifications, and fourteen days of history.
- Pro — Relay plus Patrol investigation, governed fixes, ninety days of history, centralized agent profiles, RBAC, audit logging, and reporting.
Core self-hosted monitoring is not gated by monitored-system or child-resource volume. See the runtime-aligned capability reference and current plans for details.
Documentation
- Install and deployment
- Upgrade from Pulse v5
- Configuration
- Platform and agent guides
- Pulse Intelligence
- Security and privacy
- Code signing policy
- Troubleshooting
- API reference and architecture
Localized getting started guides: Deutsch · Español
Development
Pulse uses Go 1.26 and a SolidJS/TypeScript frontend. The managed development
runtime starts the frontend at http://127.0.0.1:5173 and proxies API and
WebSocket traffic to the backend on port 7655.
npm ci
npm --prefix frontend-modern ci
npm run dev
Useful checks:
go test ./...
npm --prefix frontend-modern test
npm --prefix frontend-modern run type-check
python3 scripts/check_public_docs.py
See CONTRIBUTING.md before investing in a code change. Pulse uses an issue-first contribution process and does not normally accept unsolicited pull requests.
Community and support
- Ask questions in GitHub Discussions.
- Report reproducible bugs through GitHub Issues.
- Home Assistant users can use the community-maintained Pulse add-ons.
- If Pulse is useful to you, support its development through GitHub Sponsors or Ko-fi.
License
Pulse Community is available under the MIT License. Pulse Pro is subject to the Terms of Service.

