The Problem
Organizations managing Proxmox, Docker, and Kubernetes infrastructure need consolidated monitoring without the operational overhead of stitching together separate stacks. Most monitoring solutions either focus on one platform (Kubernetes-centric or Proxmox-centric) or require complex enterprise licensing and deployment models that are impractical for homelabs, sysadmins, and MSPs managing diverse infrastructure.
What This Does
Pulse is a unified dashboard written in Go with a React frontend that aggregates metrics, alerts, and AI-powered insights across Proxmox VE/PBS/PMG, Docker, and Kubernetes from a single interface. The codebase is organized around distinct subsystems: the cmd/pulse binary serves as the main server with command routing in cmd/pulse/main.go, while agent functionality lives in cmd/pulse-agent/main.go and cmd/pulse-host-agent/main.go. The frontend resides in frontend-modern/ with React components under src/components/, including AI chat functionality in src/components/AI/ and monitoring dashboards. Data flow is managed through Go modules that collect metadata from hosts via frontend-modern/src/api/ endpoints, and configuration is driven by .env.example and Docker compose definitions in the root directory. The project includes Helm charts under deploy/helm/pulse/ for Kubernetes deployment and uses GitHub Actions workflows in .github/workflows/ for CI/CD, with 18 test files providing coverage across the Go entry points and frontend API tests.
How To Use It
Setup: The repository provides two primary deployment paths. For Docker, the docker-compose.yml at the root and Dockerfile support containerized execution with volume persistence at pulsedata:/data. The README documents the one-liner Proxmox LXC install via curl -fsSL https://github.com/rcourtman/Pulse/releases/latest/download/install.sh | bash, which provisions the server component. Agent installation commands are generated through the UI under Settings → Agents → Installation commands, served from the /install.sh endpoint on the Pulse server.
Configuration: Environment variables are defined in .env.example at the repo root. The Helm chart values live in deploy/helm/pulse/values.yaml with schema validation in values.schema.json. For local development, .devcontainer/Dockerfile and Makefile provide build and dev container targets. The .github/workflows/publish-docker.yml and publish-helm-chart.yml workflows indicate the release pipeline.
Running it: The Go server entry point is cmd/pulse/main.go; running go run ./cmd/pulse starts the service. The frontend is initiated via frontend-modern/package.json scripts (npm start/dev). Production deployment uses the published Docker image rcourtman/pulse:latest or the Helm chart applied via kubectl apply -f deploy/helm/pulse/.
Real-World Use
A sysadmin managing both Proxmox VMs and a Kubernetes cluster can deploy Pulse once and view storage metrics, CPU usage, and network I/O across both platforms without separate agents. The AI chat assistant (BYOK, configured via frontend-modern/src/api/ai.ts) allows natural-language queries like "Why is my Proxmox node's disk latency spiking?" The Patrol system (referenced in docs/PATROL.md and docs/architecture/pulse-patrol-deep-dive.md) runs scheduled health checks and generates findings. Alerts can be routed to Discord/Slack via the notification system in frontend-modern/src/api/notifications.ts, with AI analysis optional for Pro users. A practical workflow: deploy the server via the Proxmox one-liner, install the generated agent command on a homelab node, and use the dashboard to correlate a Kubernetes pod restart event with a concurrent Proxmox storage throttling incident.
Code Health & Issues
Tests & CI: 18 test files exist across Go entry points (cmd/pulse/test.go, cmd/pulse-agent/*_test.go) and frontend API tests (frontend-modern/src/api/tests/). GitHub Actions workflows cover build, test, and release pipelines, including test-e2e.yml and build-and-test.yml. License & Security: LICENSE file present; .github/SECURITY.md and .gitleaks.toml indicate security hygiene practices are maintained. Dependency hygiene: frontend-modern/package-lock.json and Go module files are present, though a go.sum or explicit go.mod path isn't visible in the file listing - the Go tools appear to be managed through the module system implied by the cmd entries. Separation of concerns: The codebase cleanly separates server (cmd/pulse), agent (cmd/pulse-agent, cmd/pulse-host-agent), and frontend (frontend-modern/src) concerns, which is a strength for maintainability. No red flags: Tests are present, CI is configured, license is declared, and lockfiles are tracked. No evidence of secrets in config or unsafe patterns visible in the structure.
The Bottom Line
Pulse is a functional, well-structured monitoring platform that delivers on its promise of unified Proxmox/Docker/Kubernetes visibility. The Go/Rect split is clean, the installation paths are practical, and the AI features are optional rather than forced. It's best suited for teams already invested in these three platforms who need a single dashboard without the complexity of Prometheus/Grafana stacks. For homelabs or MSPs managing mixed infrastructure, it's a strong; for highly specialized or greenfield environments, the learning curve for agent deployment and AI configuration may add overhead beyond a basic Prometheus setup.
Who should use it: Sysadmins and MSPs managing Proxmox + K8s + Docker who want a unified dashboard with AI-assisted troubleshooting, BYOK flexibility, and straightforward deployment. Those already committed to the Pulse ecosystem or needing deep Proxmox integration will get the most value.