Pulse - Moses Yebei

The Problem

Monitoring Proxmox, Docker, and Kubernetes typically requires separate tools with different UIs, alerting systems, and data models. Operators end up juggling multiple dashboards, writing glue scripts, and missing cross-platform correlations. Pulse consolidates these into a single interface with unified alerting and optional AI-assisted analysis.

What This Does

Pulse is a Go backend with a React/TypeScript frontend (frontend-modern/). The backend (internal/, pkg/, cmd/) handles API serving, agent communication, and data persistence. The frontend provides the dashboard, alert configuration, and AI chat interface. Entry points in cmd/pulse-agent/main.go and cmd/eval/main.go indicate a standalone agent binary and an evaluation tool.

The system monitors Proxmox VE/PBS/PMG, Docker/Podman, and Kubernetes via agents. It supports auto-discovery, metrics history, backup exploration, and notifications to Discord, Slack, Telegram, and email. AI features (chat, patrol, alert analysis) are bring-your-own-key.

How It Is Wired

Execution starts in frontend-modern/src/App.tsx (App at line 230), which sets up WebSocket connections and routing. The call graph shows apiFetchJSON is called from 116 places and apiFetch from 61—these are the primary HTTP paths to the backend. useWebSocket (20 call sites) handles real-time updates.

Traced network paths are short: handleKeyDown → handleSubmit → apiClient.fetch (one hop to the wire). handleAnswerQuestion → answerQuestion → apiFetch → fetchJSON (two hops). The heaviest files are Alerts.tsx (77 functions, 18 types), App.tsx (40 functions), and DockerUnifiedTable.tsx (82 functions). The frontend calls out for inference (1 function), database access (1), file I/O (2), and external commands (1).

Three modules form a circular import cycle (SetupWizard.tsx, SecurityStep.tsx, CompleteStep.tsx), which complicates refactoring and increases coupling.

How To Use It

Setup: Clone and build with the included Dockerfile or docker-compose.yml. The README documents a one-liner LXC install for Proxmox and a docker run command exposing port 7655.

Configuration: Copy .env.example to .env and set required values. Backend config lives in internal/config/. Frontend dependencies are in frontend-modern/package.json.

Running: For Docker: docker run -d --name pulse -p 7655:7655 -v pulse_data:/data rcourtman/pulse:latest. Access the dashboard at http://<your-ip>:7655. Agents install via commands generated in Settings → Agents.

Real-World Use

A homelab operator with a Proxmox host, a Docker swarm, and a Kubernetes cluster installs Pulse on an LXC container. After adding credentials via the Setup Wizard, Pulse auto-discovers nodes, starts collecting metrics, and fires alerts to a Discord channel. The operator uses the AI chat to ask "Which container has the highest CPU over the last hour?" and gets an answer without querying three separate tools.

Code Health & Issues

Static analysis found 492 findings (104 high, 388 medium) across 4 kinds:

High - Deep nesting (50 instances): DiscoveryTab.tsx, HistoryChart.tsx, StepIndicator.tsx reach indentation depth 14. Flatten with early returns.
High - Import cycle (3 instances): SetupWizard.tsx, SecurityStep.tsx, CompleteStep.tsx form a circular dependency. Extract shared types.
High - Oversized files (6 instances): DiscoveryTab.tsx (914 lines), App.tsx, agent_internal_test.go. Split by responsibility.
High - Duplicated code (318 repeated 6-line blocks across 187 files): Extract shared helpers.

Security audit found 6 issues: unpinned GitHub Actions (high), discarded exit codes in create-release.yml (high), no Dependabot (medium), unpinned base image in .devcontainer/Dockerfile (medium), no dependency scan in CI (medium), missing job timeouts (low).

The Bottom Line

Pulse is a functional, feature-rich monitoring tool with a solid architecture and active CI. The frontend has real maintainability debt—deep nesting, oversized components, and duplication—that will slow future changes. It's best suited for homelab users or small MSPs wanting a single pane of glass; teams needing enterprise-grade reliability should wait for the code health issues to be addressed.

What the analyser found

Deployment readiness

7/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

1,721 files

Go1169
TSX166
TypeScript145
Markdown62
Shell49
YAML39

ReactTailwindDockerKubernetes

Module dependencies

The 10 most depended-upon modules of 307, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_src_components_AI_Chat_types["types"] n1_ents_Alerts_Thresholds_types["types"] n2_ents_SetupWizard_SetupWizard["SetupWizard"] n3_nents_Discovery_DiscoveryTab["DiscoveryTab"] n4_tend_modern_src_utils_logger["logger"] n5_odern_src_content_help_types["types"] n6_rn_src_stores_metricsHistory["metricsHistory"] n7_end_modern_src_stores_events["events"] n8_ds_components_ThresholdBadge["ThresholdBadge"] n9_rc_components_AI_aiChatUtils["aiChatUtils"] n8_ds_components_ThresholdBadge --> n1_ents_Alerts_Thresholds_types n3_nents_Discovery_DiscoveryTab --> n7_end_modern_src_stores_events classDef cyc stroke:#ef4444,stroke-width:2px; class n2_ents_SetupWizard_SetupWizard cyc;

Dependencies

9 of 25 declared dependencies are a major version behind. Resolved 25 of 25 against the registry.

Package	Declared	Latest	Behind
`@types/node`	^20.10.0	26.2.0	6 major
`jsdom`	^24.1.0	30.0.1	6 major
`typescript`	^5.3.0	7.0.2	2 major
`vite`	^6.4.2	8.2.1	2 major
`@solidjs/router`	^0.10.10	1.0.0	1 major
`lucide-solid`	^0.545.0	1.33.0	1 major
`marked`	^17.0.1	18.0.9	1 major
`@testing-library/jest-dom`	^6.5.0	7.0.1	1 major

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium3

low1

Pin third-party GitHub Actions to a commit SHAhigh6 occurrences

.github/workflows

docker/setup-qemu-action@v3, docker/setup-buildx-action@v3, docker/login-action@v3, docker/build-push-action@v6

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Stop discarding the exit code of steps whose failure mattershigh2 occurrences

.github/workflows/create-release.yml

lines 280, 292 discard failure

The job reports green while the artifact it was supposed to produce was never produced, so a crash becomes a successful run built on stale data.

Fix: Let the step fail, or test the specific expected condition instead of discarding all exit codes.

Enable Dependabot or Renovatemedium

3 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

.devcontainer/Dockerfile

golang:1.24

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set timeout-minutes on the workflow jobslow2 occurrences

.github/workflows/helm-pages.yml

2 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.