The Problem
Home and small-office network monitoring is fragmented. Speed tests tell you current throughput but not packet loss trends. Monitoring tools like Prometheus require heavy infrastructure. Distributed agents typically need complex setup. Netronome packages these capabilities into a single binary with a web UI, targeting users who want network visibility without a monitoring stack.
What This Does
Netronome is a Go backend with a React frontend, compiled into a single binary. The internal/ directory contains the core: internal/speedtest/ handles Speedtest.net, iperf3, and LibreSpeed tests; internal/speedtest/mtrunix.go and mtrwindows.go handle packet loss monitoring; internal/agent/ provides distributed server monitoring; internal/notifications/ntfy.go handles alerting. The web/ directory holds the React dashboard with API clients in web/src/api/.
The database layer supports both SQLite and PostgreSQL, with 21 migrations for each in internal/database/migrations/. The scheduler in internal/scheduler/scheduler.go handles automated test runs. Tailscale integration lives in internal/tailscale/ and internal/monitor/tailscalediscovery.go. Auth supports local accounts and OIDC via internal/auth/oidc.go.
How To Use It
The README documents two install paths: download a prebuilt binary, or use the one-liner that fetches the latest release and extracts it to /usr/local/bin. Docker users have distrib/docker/docker-compose.yml and a postgres variant.
wget $(curl -s https://api.github.com/repos/autobrr/netronome/releases/latest | grep download | grep linuxx8664 | cut -d\" -f4) tar -C /usr/local/bin -xzf netronome*.tar.gz netronome generate-config netronome serve
Configuration lives in config/config.toml (generated via generate-config). The server listens on port 7575 by default. First-run setup creates an admin account through the web UI. The Makefile provides build targets for source builds. The repo includes a Dockerfile for container builds and scripts/install-agent.sh for agent deployment.
Real-World Use
A homelab operator with multiple sites deploys Netronome at each location. The main instance runs in Docker with PostgreSQL for history retention; agents run on remote servers via scripts/install-agent.sh. The scheduler runs an iperf3 test every 6 hours against a local server, continuous MTR packet loss monitoring against the gateway, and ntfy notifications when latency exceeds a threshold. The Tailscale integration discovers other nodes on the tailnet automatically, eliminating manual agent registration.
Code Health & Issues
Med - Dual database migration drift risk - SQLite and PostgreSQL migrations are maintained separately (21 files each). Schema divergence is possible over time; the internal/database/migrationspostgrestest.go and migrationsintegrationtest.go provide some coverage but not parity guarantees. Med - Windows-specific code is stubbed - internal/speedtest/mtrwindows.go exists but internal/agent/smart_stub.go suggests SMART disk monitoring may be stubbed on some platforms. Verify platform coverage before deploying agents on mixed OS fleets. Low - Frontend test coverage is thin - 42 test files exist but are concentrated in internal/ (Go). The web/ directory has no test files listed, only linting via eslint.config.js and knip.json. Low - CI is release-focused - .github/workflows/release.yml handles releases; .github/workflows/claude.yml appears to be an AI-assist workflow. No explicit test workflow is visible, though the Makefile likely includes test targets.
The Bottom Line
Netronome is a well-structured, genuinely useful tool for network monitoring. The single-binary deployment model and low memory footprint make it practical for homelabs and small offices. The dual-database approach adds maintenance burden, and Windows agent support may be incomplete. Best for users who want network monitoring with minimal infrastructure overhead and are comfortable running a self-hosted service.