The Problem

Tracking network health across multiple sites means juggling speed tests, packet loss, and server metrics from different tools that don't share data. Netronome consolidates these into one Go binary with a web UI, targeting homelab and multi-site infrastructure operators who want a single pane of glass without heavy setup.

What This Does

Netronome is a network monitoring platform with a Go backend (internal/) and React frontend (web/). Core features: speed testing via multiple providers, continuous packet loss monitoring with MTR, distributed agents for remote server metrics, and notification alerts. The cmd/netronome/main.go entry point exposes CLI commands for serving, agent mode, and config generation.

The frontend (web/src/components/) is organized by feature: speedtest, packetloss, monitor, settings, and notifications. The backend splits cleanly into internal/agent (remote monitoring), internal/speedtest (test runners), internal/database (persistence), and internal/notifications (alerting). Configuration lives in config/config.toml with environment variable overrides handled by internal/config/config.go.

How It Is Wired

Execution starts at main in cmd/netronome/main.go:139. The runServer path (line 202) reaches 143 functions—the widest reach of any entry point. From there, internal/config/config.go's Load function calls New, which immediately hits the filesystem via sql.Open to open the database. That's two hops from entry to a side effect.

The call graph shows clear hubs. RunTestWithBothDatabases is called from 65 places—changing its signature breaks a third of the codebase. Close (54 callers) and New (34 callers) carry similar blast radius. The getEnv function is called 13 times from config loading paths, making it the de facto configuration accessor.

File responsibilities are well-separated: internal/database/database.go owns all SQL operations, internal/agent/agent.go handles remote monitoring with file I/O, internal/monitor/client.go manages broadcast and notification logic, and internal/notifications/notifications.go handles alert routing. The pkg/migrator/migrator.go manages schema migrations with both embedded and file-based sources.

How To Use It

Setup:

git clone https://github.com/moses-y/netronome
cd netronome
# Generate default config
netronome generate-config
# Start the server
netronome serve

Open http://localhost:7575, register an account, and configure providers. Docker users can use distrib/docker/docker-compose.yml for a standard setup or the .postgres.yml variant for PostgreSQL instead of the default SQLite. The Makefile provides build targets for source compilation.

Configuration: Edit config/config.toml for database, speed test providers, notification channels (ntfy, Discord, etc.), and agent settings. Environment variables override config values—the loadFromEnv → getEnv pattern in internal/config/config.go handles this.

Real-World Use

A homelab operator with three sites deploys Netronome on a central server, runs netronome agent on each remote machine. The central server schedules speed tests every 6 hours, agents stream CPU/disk metrics back, and packet loss monitors run MTR continuously. When latency exceeds thresholds, internal/notifications/notifications.go fires a Discord webhook. Historical data accumulates in SQLite or PostgreSQL, viewable through the React dashboard's time-series charts.

Code Health & Issues

Static analysis found 55 findings (11 high, 44 medium). The most concerning:

  • Critical - Secrets in fork-triggerable workflow - .github/workflows/claude.yml has ANTHROPIC_API_KEY exposed to contributor-controlled PRs. Move secret-using steps to workflow_run jobs.
  • High - Unpinned GitHub Actions - .github/workflows uses @beta and @vN tags for anthropics/claude-code-action, goreleaser, and Docker actions. Pin to commit SHAs.
  • High - Deep nesting - 34 instances, worst in web/src/components/monitor/MonitorHardwareStats.tsx (depth 10). Use guard clauses.
  • High - Duplicated code - 234 repeated 6-line blocks across 86 files, concentrated in cmd/ and internal/config/. Extract shared helpers.
  • Medium - Oversized files - NotificationSettings.tsx and ScheduleManager.tsx exceed 670 lines each.

The repo has tests (81 files), CI, Dockerfile, and license. No secrets committed. The claude.yml workflow is the immediate security concern.

The Bottom Line

A practical, well-structured network monitoring tool that delivers on its promise of single-binary deployment. The Go/React split is clean, and the call graph shows sensible separation of concerns. The workflow secret exposure is a real risk that needs fixing before accepting PRs from strangers. Worth using for homelab or small multi-site setups where lightweight deployment matters more than enterprise features.