HomeLab Monitor

One page for your whole home lab & AI rig — GPU truth (any vendor), tokens/sec, power cost by the hour, uptime, training runs, containers, disks. No agents, no separate metrics stack, no cloud.

Your home lab grew into a couple of machines, a Pi, and a GPU that's mysteriously always busy — and lately it's running models too. HomeLab Monitor gives you one self-hosted page that answers the real questions: what's that GPU actually doing, which model is holding it, what's it costing you to run, which container is eating RAM, what's filling your disks, and is anything down — across every box over SSH: Linux, a Pi, even Windows. Readable from your phone over the VPN.

Get started

# Grab the compose file and go. No GPU required — the GPU panels just light up when one's present.
curl -fsSLO https://raw.githubusercontent.com/SikamikanikoBG/homelab-monitor/main/docker-compose.yml
docker compose up -d

Open http://<your-host>:9800 and you're done. Full options (from source, GPU toolkit, Windows/WSL2) → Install docs.

🆕 v0.26 — the LLM Benchmark Lab. A new AI tab that measures what your local models actually do on your GPUs: generation & prompt tokens/sec, load time, the VRAM↔RAM split, and the largest context that still fits fully in VRAM — per card, priced like everything else in the app, stored so you only re-run when something changes. Release notes · changelog.

What you get

One page, every box, the questions you actually have. The classics are all here — and a whole AI cockpit builds on top of them.

Your GPU, demystified — and honest about it. A card pinned at "100% util" can still be throttling, memory-bandwidth-bound, or quietly drooping its clocks. The GPU tab decodes nvidia-smi's throttle reasons (a red banner the moment it's power-capped or too hot), and shows memory-bandwidth util, core/mem clocks, power-vs-limit and p-state — plus which container is holding the card. And it's no longer NVIDIA-only: AMD GPUs are read on Linux straight from the kernel's amdgpu interface (no ROCm), and AMD and Intel GPUs on Windows hosts — so your card shows up with its name, utilisation and VRAM, no vendor tools required.

What it costs — down to the process. Power becomes money: per machine, then per component (GPU measured via nvidia-smi, CPU/DRAM via RAPL), then per process, container or model — click any row to see what it drew and what it cost over any window. Day & night tariffs (Economy 7, Heures Creuses, …), or just pick your country for a sensible estimate. Every watt is measured or a baseline you set; wall power is never guessed. And a busy-hours heatmap turns months of samples into one picture of when your lab costs you money — a 7×24 day-of-week × hour grid that shows which hour of the week is priciest at a glance.

Your training runs, priced. Push a run from Jupyter, Colab or Kaggle with a one-file client (or mirror it from MLflow), and it comes back with the loss curve and the real GPU energy it burned, on the same timeline. Create, name, expire and revoke API keys yourself.

"Will it fit?" — measured, not guessed. The Benchmark Lab loads each of your local ollama models and sweeps a ladder of context sizes on your actual cards, recording generation & prompt tokens/sec, load time, how much spilled from VRAM into system RAM, and the largest context that still fits fully in VRAM — the cap worth setting. Pick which GPU(s) to test (via a throwaway pinned ollama container — your main one is never touched), overlay stored runs to compare cards, and every run comes back with the energy it burned and what it cost. Results are stored: benchmark once, re-run only when something changes.

And the rest of the lab, the way it always was:

• Containers, honestly — health plus RAM and VRAM in separate columns (real resident RAM, not page cache), and click one to tail its logs in a side drawer.
• systemd services — local or remote, your own units highlighted, failures first.
• WizTree-style disk treemaps, network I/O with per-container top talkers, and a mini-htop for who's eating CPU and RAM.
• Multi-machine over SSH — paste one key per box; Linux, a Pi, even Windows. No agents, no installs. The GPU tab works per host too: a remote multi-GPU rig shows every card's VRAM, utilisation, power and temperature, and the processes holding the memory.
• Uptime monitoring, in the box — watch any HTTP endpoint or TCP port (your services, a NAS, a remote site) straight from the container: heartbeat strip, 24h/7d uptime %, latency, and smart per-check alerts — anti-flap confirm, recovery with downtime, and an optional slow-response warning. No extra uptime service to self-host — it's already in the box.
• Push alerts — Discord, ntfy.sh and Telegram, edge-triggered so they don't spam.

Full tab-by-tab tour → Features.

Multi-machine, in two sentences

Open the Hosts tab, paste the hub's auto-generated SSH key onto each remote, and the hub starts polling it — no agents, just SSH + Python 3 (PowerShell on Windows). The hub pipes a small self-contained probe over SSH; nothing persists on the remote.

Onboarding, Windows setup, and the security model → Multi-machine docs.

Configuration

Set these under environment: in docker-compose.yml (all optional):

History lives in ./data/gpu.db (a bind mount), so it survives restarts and upgrades. Alerts, the systemd D-Bus mount, and per-server tuning → Configuration docs.

Under the hood

The hub stitches nvidia-smi (plus AMD GPUs via the in-kernel amdgpu sysfs interface, and AMD/Intel on Windows hosts via the built-in GPU perf counters), the Docker API, model-server APIs (Ollama, vLLM, llama.cpp, A1111, …), systemd D-Bus, and /proc + /sys into one sampled view, persisted to SQLite and downsampled on read so a six-month range loads as fast as the last hour. Single page, vendored Chart.js, no build step.

• 30+ recognised model servers → Model servers
• Standard /metrics endpoint to scrape into whatever dashboards you already run → Metrics export
• The full data pipeline + caller attribution → How it works

Connect an AI agent (MCP)

Your homelab is now legible to AI agents — point a client at one URL and it can see every host, container, GPU and disk. Read-only, no extra setup.

HomeLab Monitor isn't just a dashboard for you anymore; it's context for your AI agent too. A read-only MCP server is built into the same container (served on :9810) — so Claude, Claude Code, or any MCP client connects in one line and explores your whole lab through 19 named tools, with the same coverage you see on the dashboard: hosts, containers, systemd services, GPU and who's driving it, per-process RAM, AI model