cef057943a
Mock pages were sparse: 3 Proxmox nodes × 3 VMs × 3 LXCs, 2 Docker hosts × 5 containers, 1 K8s cluster × 3 nodes × 10 pods × 4 deployments. That populated platform pages with handfuls of rows rather than table density that exercises sorting, grouping, drawers, and responsive layout. Bump `internal/mock/generator.go::DefaultConfig` to target a mature small-to-mid homelab / SMB environment: - NodeCount: 3 → 5 (matches the curated demo scenario's pve1..pve5 regional naming) - VMsPerNode: 3 → 6 - LXCsPerNode: 3 → 8 - DockerHostCount: 2 → 5 - DockerContainersPerHost: 5 → 14 - GenericHostCount: 2 → 4 - K8sClusterCount: 1 (unchanged; the curated demo and broadcast coalesce tests assume a single cluster identity) - K8sNodesPerCluster: 3 → 5 - K8sPodsPerCluster: 10 → 40 - K8sDeploymentsPerCluster: 4 → 14 Resource survey under the new defaults (live mock backend): - TOTAL 307 unique resources (was ~50-100) - app-container: 75, storage: 55, system-container: 44, pod: 40, vm: 31, physical_disk: 19, agent: 15, k8s-deployment: 14, docker-host: 5, network-endpoint: 5, pmg: 2, pbs: 1, k8s-cluster: 1 Platform pages now feel populated under mock mode: - /docker/overview: 5 hosts (was 2) - /docker/containers: 75 containers (was 13) - /kubernetes/nodes: 5 (was 3) - /kubernetes/pods: 40 (was 10) - /kubernetes/deployments: 14 (was 4) `internal/mock/demo_scenarios.go` extended to season `local`, `local-zfs`, and per-node iso/service-pool storage names for pve6 and beyond, so future NodeCount bumps don't regress the curated demo into generic "service-pool" labels (a test guard explicitly forbids that alias). A new `TestDemoScenarioStorageNamingHandlesScaledNodeCount` covers the scaled-NodeCount path. `internal/monitoring/monitor_unified_state_test.go` updated to compare the broadcast count against the coalesced snapshot count rather than the raw snapshot count — the broadcast path merges resources that share a canonical host key (K8s nodes onto linked agent hosts), so larger fixture sizes legitimately produce more merge candidates, and the prior raw-equality assertion would have broken on any future fixture growth too. The test still asserts every canonical name and mock identity it checked before. `scripts/toggle-mock.sh` (`mock_default_entries`) and the matching `scripts/tests/test-toggle-mock.sh` assertions are aligned with the new defaults so `npm run mock:edit` and per-dev `.env` seeding match the canonical baseline. Contracts updated: - `monitoring.md` Shared Boundaries: records the new DefaultConfig target sizes and the requirement that demo-scenario seasoning stay aligned with NodeCount changes. - `deployment-installability.md` Shared Boundaries: records that `mock_default_entries()` in toggle-mock.sh must stay aligned with `internal/mock.DefaultConfig` so CLI/toggle/runtime mock densities never drift apart. Targeted Go tests: - `go test ./internal/mock/...` green - `go test ./internal/monitoring/...` green Playwright (chromium, live mock-mode dev runtime): - 9 tests, all pass; populated assertions now hit dense tables (5 hosts, 14+ containers, 40 pods, etc.). Known remaining fixture gaps (canonical adapter, not config): - VMware fixture inventory in `internal/vmware/fixtures.go` is hardcoded at 4 hosts / 6 VMs / 4 datastores; not scaled in this commit. - TrueNAS fixture inventory in `internal/truenas/fixtures.go` is similarly hardcoded; not scaled in this commit. |
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| .husky | ||
| cmd | ||
| deploy/helm/pulse | ||
| dev/oidc | ||
| docs | ||
| frontend-modern | ||
| internal | ||
| pkg | ||
| scripts | ||
| testing-tools | ||
| tests | ||
| .air.toml | ||
| .dockerignore | ||
| .env.example | ||
| .gitattributes | ||
| .gitguardian.yaml | ||
| .gitignore | ||
| .gitleaks.toml | ||
| .golangci.yml | ||
| .markdownlint-cli2.jsonc | ||
| .markdownlint.json | ||
| analyze_coverage.py | ||
| ARCHITECTURE.md | ||
| artifacthub-repo.yml | ||
| audit_report.md | ||
| CONTRIBUTING.md | ||
| cr.yaml | ||
| docker-compose.yml | ||
| docker-entrypoint.sh | ||
| docker-healthcheck.sh | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| install.sh | ||
| LICENSE | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| playwright.config.ts | ||
| README.md | ||
| SECURITY.md | ||
| TERMS.md | ||
| VERSION | ||
Pulse
Real-time monitoring for Proxmox, Docker, Kubernetes, and TrueNAS infrastructure.
Issue-first contribution policy: please open an issue or discussion before investing time in a code change. External pull requests are not part of the normal contribution flow for this repository. See CONTRIBUTING.md.
🚀 Overview
Pulse is a modern, unified monitoring workspace for your infrastructure across Proxmox, Docker, Kubernetes, and TrueNAS. It consolidates metrics, alerts, and AI-powered insights from all your systems into a single, beautiful interface.
Designed for homelabs, sysadmins, and MSPs who need a "single pane of glass" without the complexity of enterprise monitoring stacks.
🧭 Unified Navigation
Pulse now groups everything by task instead of data source:
- Infrastructure for hosts and nodes
- Workloads for VMs, containers, and Kubernetes pods
- Storage and Backups as top-level views
- PMG now routes into Infrastructure (source filter), and Kubernetes routes into Workloads (K8s filter)
- Legacy URLs are no longer routed as compatibility aliases; use canonical v6 routes.
Power-user shortcuts:
g i→ Infrastructure,g w→ Workloads,?→ shortcuts help/orCmd/Ctrl+K→ global search
✨ Features
Core Monitoring
- Unified Monitoring: View health and metrics for PVE, PBS, PMG, Docker, Kubernetes, and TrueNAS in one place
- Smart Alerts: Get notified via Discord, Slack, Telegram, Email, and more
- Auto-Discovery: Automatically finds Proxmox nodes on your network
- Metrics History: Persistent storage with configurable retention
- Recovery Central: Unified backup/snapshot/replication timeline across PBS and TrueNAS
AI-Powered
- Chat Assistant (BYOK): Ask questions about your infrastructure in natural language
- Patrol: Background health checks that generate findings on a schedule. Community self-hosted installs can run Patrol with your own AI provider or a local model.
- Alert Analysis (Pro / hosted Cloud): Optional AI analysis when alerts fire
- Cost Tracking: Track usage and costs per provider/model
Multi-Platform
- Proxmox VE/PBS/PMG: Full monitoring and management
- TrueNAS: Pools, datasets, disks, ZFS snapshots, replication tasks, and alerts
- Kubernetes: Complete K8s cluster monitoring via agents
- Docker/Podman: Container and Swarm service monitoring
- OCI Containers: Proxmox 9.1+ native container support
Security & Operations
- Secure by Design: Credentials encrypted at rest, strict API scoping, agent commands disabled by default
- One-Click Updates: Easy upgrades for supported deployments
- OIDC/SSO/SAML: Single sign-on with multi-provider support
- Mobile Remote Access: Relay protocol with end-to-end encryption for supported Pulse Mobile clients (Relay and above)
- Privacy Focused: Anonymous outbound telemetry is enabled by default and fully documented — no hostnames, credentials, or personal data is ever sent. Disable any time in Settings or via
PULSE_TELEMETRY=false.
⚡ Quick Start
Paid Pulse Pro / Relay / legacy customers: GitHub release assets and the public
rcourtman/pulseDocker image are community builds. They can accept an activation key, but they do not include the private Pulse Pro runtime hooks. Use https://pulserelay.pro/download.html with your activation key to get the private Pulse Pro Docker image or Linux archive.
Option 1: Proxmox LXC (Recommended)
Replace vX.Y.Z with the exact release tag you want, verify the signed installer, then run it on your Proxmox host:
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' '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
Note: this installs the Pulse server. Agent installs use the command generated in Settings → Unified Agents → Installation commands (served from /install.sh on your Pulse server).
Option 2: Docker
docker run -d \
--name pulse \
-p 7655:7655 \
-v pulse_data:/data \
--restart unless-stopped \
rcourtman/pulse:vX.Y.Z
Open Pulse at http://<your-ip>:7655.
Local Development
Use the managed dev runtime from the repo root:
npm run dev
Open http://127.0.0.1:5173 in the browser. 5173 is the frontend dev shell,
and it proxies /api and /ws to the backend on 7655. 7655 is the backend
dependency for API and websocket traffic, not the primary browser URL for local
frontend development.
The managed dev runtime resets its local login to admin / adminadminadmin
on startup unless you override it with HOT_DEV_AUTH_USER and
HOT_DEV_AUTH_PASS.
Canonical local dev commands:
npm run dev— start the managed runtime and reclaim the canonical dev ports if an older unmanaged session is still using themnpm run dev:status— show frontend shell health, proxied API health, direct backend health, and listener ownershipnpm run dev:verify— run the managed browser proof pack against the live dev runtime, including runtime recovery, the Patrol blocked-runtime page contract, and the desktop Recovery layout guard while the launcher suppresses unrelated backend rebuild churn for the duration of the proof packnpm run dev:logs— tail the managed runtime lognpm run dev:backend-restart— bounce only the managed backend through the launcher contractnpm run dev:stop— stop the managed runtimenpm run dev:foreground— run the foreground hot-reload launcher intentionally if you need an attached shell
If npm run dev:verify passes, the managed dev shell, proxy path, backend
health endpoint, browser recovery path, Patrol blocked-runtime page behavior,
and Recovery desktop history-table layout are all aligned.
📚 Documentation
- Installation Guide: Detailed instructions for Docker, Kubernetes, and bare metal.
- Upgrade to v6: Migration guide for upgrading from v5 to v6.
- Configuration: Setup authentication, notifications, and advanced settings.
- Security: Learn about Pulse's security model and best practices.
- API Reference: Integrate Pulse with your own tools.
- Architecture: High-level system design and data flow.
- AI Features: Pulse Assistant (Chat) and Pulse Patrol documentation.
- Multi-Tenant: Enterprise multi-tenant setup and configuration.
- Troubleshooting: Solutions to common issues.
- Agent Security: Agent privilege model, Proxmox API-only choices, and checksum/signature verification.
- Docker Monitoring: Setup and management of Docker agents.
- Unified Navigation: Guide to the new task-based navigation.
🌐 Community Integrations
Community-maintained integrations and addons:
- Home Assistant Addons - Run Pulse Agent and Pulse Server as Home Assistant addons.
💳 Plans (Community / Relay / Pro / Cloud)
Pulse is full-featured for core monitoring in every self-hosted tier. Self-hosted pricing no longer sells more room for monitoring volume; paid value comes from convenience, history, AI operations, and advanced administration. Cloud and MSP pricing are unchanged.
Self-hosted tiers:
| Plan | Price | Core monitoring | Metric history | Main value |
|---|---|---|---|---|
| Community | Free | Included | 7 days | Full self-hosted monitoring |
| Relay | $39/yr or $4.99/mo | Included | 14 days | Remote web access, mobile app pairing, and push notifications |
| Pro | $79/yr or $8.99/mo | Included | 90 days | Root-cause analysis, safe remediation workflows, and operations tooling |
Pulse still counts top-level monitored systems once no matter how they are collected. VMs, containers, pods, disks, backups, and other child resources under that system are included rather than counted separately, but that count is no longer the self-hosted paid gate.
Community keeps Patrol available with your own provider or local model. Relay remains the convenience tier, and Pro is the paid operations tier.
Runtime-aligned capability summary:
| Capability | Community | Relay | Pro | Cloud |
|---|---|---|---|---|
| Pulse Patrol (Background Health Checks) | ✅ | ✅ | ✅ | ✅ |
| Remote Access / Mobile / Push | — | ✅ | ✅ | ✅ |
| Alert-Triggered Root-Cause Analysis | — | — | ✅ | ✅ |
| Safe Remediation Workflows | — | — | ✅ | ✅ |
| Centralized Agent Profiles | — | — | ✅ | ✅ |
| Update Alerts (Container/Package Updates) | ✅ | ✅ | ✅ | ✅ |
| SSO (OIDC/SAML/Multi-Provider) | ✅ | ✅ | ✅ | ✅ |
| Role-Based Access Control (RBAC) | — | — | ✅ | ✅ |
| Enterprise Audit Logging | — | — | ✅ | ✅ |
| Advanced Infrastructure Reporting (PDF/CSV) | — | — | ✅ | ✅ |
| Extended Metric History | 7 days | 14 days | 90 days | 90 days |
Pulse Patrol runs on your schedule (every 10 minutes to every 7 days, default 6 hours) and finds:
- ZFS pools approaching capacity
- Backup jobs that silently failed
- VMs stuck in restart loops
- Clock drift across cluster nodes
- Container health check failures
On self-hosted installs, Pulse Patrol uses the provider you configure from your Pulse server. That can be a commercial API key or a local model endpoint. Chat Assistant follows the same self-managed provider model.
Technical highlights:
- Cross-system context (nodes, VMs, backups, containers, and metrics history)
- LLM analysis with your provider plus alert-triggered root-cause investigations (Pro / hosted Cloud)
- Optional safe remediation execution with command safety policies and audit trail
- Centralized agent profiles for consistent fleet settings
Try the live demo → or learn more at pulserelay.pro
Pulse plan technical details: docs/PULSE_PRO.md
❤️ Support Pulse Development
Pulse is maintained by one person. Sponsorships help cover the costs of the demo server, development tools, and domains. If Pulse saves you time, please consider supporting the project!
📄 License
MIT © Richard Courtman. Use of Pulse Pro is subject to the Terms of Service.