Skip to main content

Why I Picked Rust for a Dashboard That Sits Idle All Day

GC pauses, static binaries, Tokio concurrency. Developer brain dump on language choice for AMUD.

By Youssef Boubli · Creator of AMUD Dashboard

A homelab dashboard is a weird workload. It idles 99% of the time but still needs to poll metrics every few seconds, hold WebSocket connections, encrypt secrets, and never leak memory over months of uptime.

That's systems programming territory. Not "spin up Express and call it a day" territory.

Why not Node​

I've run plenty of Node homelab tools. V8 heap sitting at 80–150MB for a bookmark page hurts when that box also runs Jellyfin and Sonarr. GC pauses during telemetry polling are rare but annoying when you're staring at a graph that stutters.

Why not Go​

Go would've been fine honestly. I picked Rust because I wanted memory safety without a GC, static binaries with embedded assets (include_str! for UI templates), and Tokio's async model for concurrent integration polls.

The stack that stuck​

  • Axum — HTTP + WebSockets
  • rusqlite — embedded config, WAL mode
  • hyper + rustls — Proxmox HTTPS
  • hyperlocal — Docker socket
  • Argon2id — passwords

Compile once, drop binary on host, run. No runtime install step.

Trade-offs I'll admit​

Rust compile times are slow. Contributor pool is smaller than JS. I occasionally fight the borrow checker at 2am.

For a long-running daemon on a 256MB LXC though? I'd make the same call again.

Architecture: /docs/ARCHITECTURE

Want to hack on it: github.com/boubli/AMUD-Dashboard