HomeLab Monitor

One page, every box, the questions you actually have. The classics are all here — and a wholeAI cockpitbuilds on top of them.

Your GPU, demystified — and the same tab on every box.A card pinned at "100% util" can still be throttling, memory-bandwidth-bound, or quietly drooping its clocks. The GPU tab decodesnvidia-smi's throttle reasons, and shows memory-bandwidth util, core/mem clocks, power-vs-limit, p-state — andfan speed— foreverymachine in the fleet, not just the one running the container. Multi-GPU boxes get one panel per card on a shared scale per metric, so a taller temperature line really is a hotter card; thermal-throttle windows are shaded right on the sparkline. You can seewhich carda service is sitting on (a 3×3090 box shows a model's 63 GB split 22.5 / 22.1 / 18.8 across the cards, not one pooled number), what each service cost in energy, and get alerted when a card throttles, overheats or loses a fan — sustained, per card, with per-host thresholds, because a box running a deliberately lowered power limit issupposedto sit at its cap. And it's no longer NVIDIA-only:AMDGPUs are read on Linux straight from the kernel'samdgpuinterface (no ROCm), andAMD and IntelGPUs on Windows hosts — so your card shows up with its name, utilisation and VRAM, no vendor tools required. Anything a driver won't report says so, instead of drawing a confident zero.

What it costs — down to the process.Power becomes money: per machine, then per component (GPU measured vianvidia-smi, CPU/DRAM via RAPL), thenper 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 abusy-hours heatmapturns months of samples into one picture ofwhenyour 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 curveandthe real GPU energy it burned, on the same timeline. Create, name, expire and revoke API keys yourself.

"Will it fit?" — measured, not guessed.TheBenchmark Labloads 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 thelargest 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 plusRAM 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 — on any box in the fleet.Click into the folders filling a disk on the huboron any Linux host you've added; a remote is scanned over the same SSH connection everything else uses, so there's still nothing to install on it. Plusnetwork I/O with per-container top talkersand amini-htopfor who's eating CPU and RAM.
- It moves like a live dashboard.Utilisation, RAM, temperature and power update every couple of seconds over a push stream instead of a fixed poll — and it does that while makingfewerrequests than before, because the expensive history query is fetched only as often as its own chart buckets can change, and a tab you're not looking at stops costing anything at all. Sampling and storage cadence are untouched, so history stays exactly as dense (and costs stay exactly as accurate) as they were.
- Multi-machine over SSH— paste one key per box; Linux, a Pi, evenWindows. No agents, no installs. The GPU tab works per host too: a remote multi-GPU rig showsevery card's VRAM, utilisation, power and temperature, and the processes holding the memory.
- Uptime monitoring, in the box— watch anyHTTP endpoint or TCP port(your services, a NAS, a remote site) straight from the container: heartbeat strip, 24h/7d uptime %, latency, andsmart 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.shandTelegram, edge-triggered so they don't spam.

Open theHoststab, 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. The same connection is what lets you open a remote'sGPU cockpitandscan its disksfrom the hub — still with nothing installed on the far end.

Set these underenvironment:indocker-compose.yml(all optional):

The hub stitchesnvidia-smi(plus AMD GPUs via the in-kernelamdgpusysfs 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+/sysinto 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.

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.

Connect any MCP client — Claude, ChatGPT, or an agent on your own local Ollama models — and it reads your homelab's live state. Read-only: both directions are just question and answer.

# the dashboard is on :9800; the MCP server rides along on :9810 claude mcp add --transport http homelab http://YOUR-HUB:9810/mcp

Once connected, skip the tab-hunting and justask— the agent picks the right tools:

- "My GPU's been pinned for an hour — which model server is loaded, and who's actually calling it?"
- "What's eating/backup? Give me the biggest folders and flag anything that looks like runaway logs."
- "Which host is lowest on RAM right now, and what's the top process holding it?"
- "I want to reboot and run an OS upgrade this weekend — which box needs it most, and what's a safe order given what's running on each?"

If HomeLab Monitor saves you a browser tab or two, a ⭐ on GitHub genuinely helps other home-labbers find it. Thank you!

Bring a friend, post an idea, open an issue — let's grow a friendly, healthy homelab community. 💛

MCP servers for managing homelab infrastructure through Claude Desktop. Monitor Docker/Podman containers, Ollama AI models, Pi-hole DNS, Unifi networks, and Ansible inventory.

claw machine gives any agent access to the users local scoped docker socket.

Civilian situational awareness for AI deployments — real-time risk dashboards, multi-source threat correlation, anomaly detection, and automated alerting for critical infrastructure and enterprise AI systems.

MCP server to Automate Exposure Management

Monitor WAF events, analyze attacks, tune rules and whitelist IPs for OWASP ModSecurity CRS via Docker

Manage and interact with Microsoft Azure services.

The IBM Instana MCP server enables seamless interaction with the IBM Instana observability platform, allowing you to access real-time observability data directly within your development workflow.

Query and interact with kubernetes environments monitored by Metoro

Integrates with Alibaba Cloud APIs to manage resources like ECS, Cloud Monitor, and OOS.