Cold seven-day mock workload charts synthesized 914 values per series before discarding most of them. Selecting the existing timestamp grid before synthesis preserves the retained readings, newest point and complete history window while bounding expensive work. The controlled native request fell from 8.9 seconds to 1.3 seconds. The strict chart query gate also exceeded its 90 ms p95 limit. Profiling showed repeated SQLite row decoding, so raw fleet value reads now carry the series and timestamp in one integer per observation. This statement-local transport preserves exact values, negative-epoch timestamps, tier reconciliation, resource scope and ordering, with separate columns when a window could overflow. Full metrics-store tests and targeted monitoring/API regressions pass, including boundary and prepared-query cache controls. The 90 ms limit remains unchanged. Organization browser fixtures arrange activated API fixtures before their first workspace load. Explicit activation and deletion bounds cover the existing server deadlines. Cleanup owns partial preparation, attempts every tracked organization and retains failures. Native backend teardown retains its final log. CI executes all 63 authentication, organization and backend lifecycle controls before browser fanout. Browser OS acquisition uses the hosted runner's existing signed Ubuntu source definition. An unrelated Microsoft feed returning 403 can no longer stop browser setup. Missing, unreadable or empty Ubuntu definitions and incomplete Ubuntu index updates still fail. Existing mirror, TLS, signature and cached archive hash checks remain in force. Real apt acquisition controls, 17 package cache tests, 11 ownership tests and normal commit/push checks pass. The mock target lookup benchmark keeps fixture lifecycle logs out of Go's result stream. A combined stdout/stderr control reproduces the lost original observations and parses all ten corrected observations with identical 4,731 lookups per operation. The benchmark work and comparison thresholds remain unchanged. Current-build browser verification covers `/proxmox/workloads?type=vm&platform=proxmox-pve` at 1440×1000 and 390×844: seven-day trends, row drawer expansion, history range selection, oldest/latest keyboard inspection and drawer dismissal. Twelve organization-route cases cover organization settings, access, sharing and billing across Chromium, mobile Chrome and mobile Safari with retries disabled. The [full stable/probation browser run](https://github.com/rcourtman/Pulse/actions/runs/40160832317) passed: 530 passed, 392 skipped, zero failures and no retry/flaky markers in all eight shard logs. Agent registration and organization provisioning also passed. This evidence covers product code at64c0a3f9. The later correction changes only a Go benchmark fixture and its performance contract. The [final-head stable E2E run](https://github.com/rcourtman/Pulse/actions/runs/40163545118) also passed all eight shards, agent registration and organization provisioning: 186 passed, 183 skipped, zero failures. All nine required source checks passed. The [final-head build and test run](https://github.com/rcourtman/Pulse/actions/runs/40163545117) passed, including benchmark comparison and strict chart qualification. The chart result on valid hosted capacity was p50 38.31 ms, p95 51.01 ms and p99 52.28 ms against the unchanged 90 ms p95 limit. The retained artifact binds the measured binary to the tested synthetic merge commit. The preceding runtime qualification also passed at p95 86.55 ms on its runner. The benchmark comparison found no regression above the existing 10% and p<0.05 threshold. The corrected lookup fixture supplied all ten observations without parser warnings. After main advanced with scoped authentication and tenant runtime changes, a native compatibility proof composed this exact head withc809d3c93b. API, configuration API and monitoring regressions passed. All twelve organization browser cases passed again with retries disabled. A fresh embedded runtime passed the desktop and phone seven-day chart matrix with both endpoints accessible. The reviewed combined tree is2e9a154b1c.
Pulse documentation
Start here for installation, platform setup, security, operations, and Pulse Intelligence. Commands, configuration keys, image names, API fields, and product identifiers remain untranslated in localized guides.
Need help with a failure? Read the safe reporting guidance before sharing evidence. A second reproduction or diagnostics export is not required; keep the original evidence if another attempt could interrupt workloads or send duplicate notifications. GitHub reports and attachments are public: review them locally and keep credentials and private details out.
Start here
- Install Pulse — signed Proxmox/Linux installation, Docker, Docker Compose, Kubernetes, and first-run setup.
- Production deployment and security — least-privilege Proxmox setup, root-agent boundaries, discovery, supply-chain verification, plan limits, scale evidence, and a rollout checklist.
- Upgrade from Pulse v5 — migration prerequisites, rollback, agent continuity, and post-upgrade checks.
- Releases and update channels: choosing Stable or Preview, beta and RC expectations, and how releases are tested and promoted.
- Configure Pulse — authentication, notifications, discovery, retention, and system settings.
- Deployment models — data locations, lifecycle, and differences between supported deployment paths.
- Troubleshooting and FAQ — common failures, diagnostics, and operator questions.
Localized getting started guides: Deutsch · Español
Platforms and agents
- Proxmox Backup Server
- Proxmox Mail Gateway
- Docker and Podman
- Kubernetes and Helm
- TrueNAS SCALE and CORE
- Unified Agent
- Agent security
- VM disk monitoring
- ZFS monitoring
- Temperature monitoring
VMware vSphere support is early access. Current builds expose dedicated vSphere inventory and recovery context, but operators should validate the integration against their own vCenter before production use.
Monitoring and operations
- Metrics history
- Recovery data
- Webhooks
- Automatic updates
- Centralized agent management (Pro)
- Operational trust model
- Current product screenshots
Pulse Intelligence
- Assistant, Patrol, and external-agent overview
- Patrol modes and safety
- Assistant safety model
- External agent HTTP and MCP substrate
Patrol watch-only analysis is available on Community with a local model or the operator's own provider. Investigation and governed fixes require the relevant Pulse Pro capabilities.
Security, privacy, and access
- Production deployment and security
- Security review scope
- Authentication and credential storage review packet
- Security guide
- Privacy and telemetry disclosure
- OIDC and SSO
- Proxy authentication
- Role-based access control (Pro)
- Audit logging (Pro)
- Reverse proxy configuration
- Code-signing policy
Plans and managed access
- Community, Relay, and Pro capabilities
- Relay and Pulse Mobile handoff
- Multi-tenant organizations (Enterprise/custom)
- Provider-hosted MSP operations (request-assisted)
Pulse Cloud is not generally available. Ordinary self-hosted Pulse remains the primary installation path; MSP and Enterprise access are explicit commercial paths rather than defaults in self-hosted setup.
Development and reference
Detailed design notes and dated migration specifications may remain in this directory for maintainers, but they are not operator setup guides unless they are linked from the sections above.
Previous versions and migrations
- Upgrade from v4 to v5
- Retired unified-navigation migration — historical context only; current Pulse uses platform-shaped navigation.
- Move a Pulse installation
Found a bug? Use the issue forms. For setup questions, use GitHub Discussions.