BODY — copy from here ↓
Series: Building AMUD — Part 4 of 12
Part 1: Why I Built AMUD in Rust
GitHub: https://github.com/boubli/AMUD-Dashboard
Most homelab dashboards get CPU and container stats by running docker stats, pvesh, or curl in a loop. Every poll = new subprocess = wasted CPU.
AMUD collects telemetry natively in Rust.
Quick facts
| Component | Role |
|---|---|
amud-agent |
Collects host + container metrics |
amud-server |
Broadcasts to browsers via WebSocket |
| Tokio | Async polling on green threads |
| IPC | Unix domain socket (or TCP on Windows) |
Idle footprint: ~26–35MB for server + agent combined.
The old way vs AMUD
| Approach | Problem |
|---|---|
Shell out to pvesh get ...
|
New process every few seconds |
curl Proxmox API in bash |
Parsing overhead, fragile |
| Docker CLI polling | Slow, permission-heavy |
The AMUD way
Host metrics: read directly from /proc and /sys — no subprocess.
Proxmox LXC/VM status: native HTTPS REST calls via hyper + rustls to the Proxmox API (port 8006).
Docker: read the Docker daemon over the Unix socket via hyperlocal — no docker stats CLI.
Browser updates: amud-server uses a tokio::sync::watch channel. One poll tick → serialize once → push to all WebSocket clients.
Result: live CPU, RAM, disk, and network graphs that update smoothly without freezing the UI.
Agent ↔ server security
The agent must authenticate before sending telemetry — challenge-response with a shared secret (AMUD_AGENT_SECRET). Random processes can't inject fake metrics.
Architecture docs: https://boubli.github.io/AMUD-Dashboard/docs/ARCHITECTURE
What you see on the dashboard
- Host CPU / RAM / disk bars (real-time)
- Per-app RUNNING / STOPPED when linked to LXC CTID or Docker name
- Integration badges (Plex streams, Pi-hole queries, etc.) polled concurrently
Setup reminder
- Install AMUD (Proxmox or Docker)
- Ensure
amud-agentis running - Add Proxmox API token in Settings if you use LXC status
Next: Green/red LXC badges and start/stop from the dashboard.
Top comments (0)