HomeLab Monitor
Servidor MCP de solo lectura dentro de un panel de control autogestionado para el laboratorio doméstico: explore hosts, contenedores Docker, GPU/VRAM, servicios systemd, modelos de IA, alertas y discos.
Documentación
HomeLab Monitor
Una sola página para todo tu laboratorio doméstico y tu equipo de IA: la verdad sobre la GPU (cualquier fabricante), tokens/segundo, costo de energía por hora, tiempo de actividad, ejecuciones de entrenamiento, contenedores, discos. Sin agentes, sin stack de métricas separado, sin nube.
Tu laboratorio doméstico creció hasta convertirse en un par de máquinas, una Pi y una GPU que misteriosamente está siempre ocupada — y últimamente también ejecuta modelos. HomeLab Monitor te da una página autoalojada que responde las preguntas reales: qué está haciendo realmente esa GPU, qué modelo la está usando, cuánto te cuesta ejecutarla, qué contenedor está consumiendo RAM, qué está llenando tus discos y si algo está caído — en todas las máquinas vía SSH: Linux, una Pi, incluso Windows. Legible desde tu teléfono a través de la VPN.
Comenzar
# 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
Abre http://<your-host>:9800 y listo. Opciones completas (desde el código fuente, kit de herramientas GPU, Windows/WSL2) → Documentos de instalación.
🆕 Qué hay de nuevo — cada versión está documentada por completo, con el razonamiento detrás: última versión · registro de cambios. El panel también te muestra las notas una vez, dentro de la aplicación, después de que se actualice solo.
Lo que obtienes

Una página, cada máquina, las preguntas que realmente tienes. Los clásicos están todos aquí — y una cabina de IA completa se construye sobre ellos.
Una página principal para tu laboratorio — y una pantalla de pared. La Vista General abre con un Launchpad: las aplicaciones que realmente abres, como mosaicos con sus logotipos reales, fijados directamente desde una fila de contenedor con la dirección ya completada, agrupados y arrastrados al orden que quieras. Los fijados viven en el concentrador, no en un solo navegador — fíjalo en la laptop y estará en el teléfono y en la pared. Todo el tablero se ajusta a la pantalla: mide su propio desbordamiento después de cada renderizado y cede espacio en orden — recortando listas, apretando el carril de flota, plegando fijados detrás de un +N más — en lugar de cortar una tarjeta por la mitad o pasar más allá del pliegue. Verificado desde 4K hasta 1366×768. Y ⛶ Pantalla (o /?display=1, todo lo que necesita una caja kiosco dedicada) elimina cada fragmento de interfaz y llena el monitor: tú eliges qué paneles muestra la pared, y en navegadores basados en Chromium se abre a pantalla completa en la pantalla que le indiques.
Tu GPU, desmitificada — y la misma pestaña en cada máquina. Una tarjeta fijada en "100% de utilización" aún puede estar estrangulada, limitada por ancho de banda de memoria, o bajando silenciosamente sus relojes. La pestaña GPU decodifica las razones de estrangulamiento de nvidia-smi, y muestra utilización de ancho de banda de memoria, relojes de núcleo/memoria, potencia vs. límite, estado-p — y velocidad del ventilador — para cada máquina en la flota, no solo la que ejecuta el contenedor. Las máquinas multi-GPU obtienen un panel por tarjeta en una escala compartida por métrica, así que una línea de temperatura más alta realmente es una tarjeta más caliente; las ventanas de estrangulamiento térmico están sombreadas directamente en el minigráfico. Puedes ver qué tarjeta está usando un servicio (una caja 3×3090 muestra los 63 GB de un modelo divididos 22.5 / 22.1 / 18.8 entre las tarjetas, no un número combinado), cuánto costó cada servicio en energía, y recibir alertas cuando una tarjeta se estrangula, se sobrecalienta o pierde un ventilador — sostenido, por tarjeta, con umbrales por host, porque una caja con un límite de potencia deliberadamente reducido debe estar en su tope. Y ya no es solo NVIDIA: las GPU AMD se leen en Linux directamente desde la interfaz amdgpu del kernel (sin ROCm), y las GPU AMD e Intel en hosts Windows — así que tu tarjeta aparece con su nombre, utilización y VRAM, sin herramientas del fabricante. Cualquier cosa que un controlador no reporte lo dice, en lugar de dibujar un cero confiado.

Cuánto cuesta — hasta el proceso. La potencia se convierte en dinero: por máquina, luego por componente (GPU medida vía nvidia-smi, CPU/DRAM vía RAPL), luego por proceso, contenedor o modelo — haz clic en cualquier fila para ver qué consumió y cuánto costó en cualquier ventana de tiempo. Tarifas de día y noche (Economy 7, Heures Creuses, …), o simplemente elige tu país para una estimación razonable. Cada vatio se mide o es una línea base que tú estableces; la potencia de pared nunca se adivina. Y un mapa de calor de horas ocupadas convierte meses de muestras en una imagen de cuándo tu laboratorio te cuesta dinero — una cuadrícula de 7×24 de día-de-la-semana × hora que muestra qué hora de la semana es la más cara de un vistazo.

Tus ejecuciones de entrenamiento, con precio. Envía una ejecución desde Jupyter, Colab o Kaggle con un cliente de un solo archivo (o reflejala desde MLflow), y vuelve con la curva de pérdida y la energía real de GPU que quemó, en la misma línea de tiempo. Crea, nombra, expira y revoca claves API tú mismo.

"¿Cabe?" — medido, no adivinado. El Laboratorio de Benchmarks carga cada uno de tus modelos locales de ollama y barre una escalera de tamaños de contexto en tus tarjetas reales, registrando tokens/segundo de generación y de prompt, tiempo de carga, cuánto se derramó de VRAM a RAM del sistema, y el contexto más grande que aún cabe completamente en VRAM — el límite que vale la pena establecer. Elige qué GPU(s) probar (a través de un contenedor ollama fijado desechable — tu principal nunca se toca), superpón ejecuciones almacenadas para comparar tarjetas, y cada ejecución vuelve con la energía que quemó y cuánto costó. Los resultados se almacenan: haz benchmark una vez, vuelve a ejecutar solo cuando algo cambie.

Y el resto del laboratorio, como siempre fue:
- Contenedores, honestamente — salud más RAM y VRAM en columnas separadas (RAM residente real, no caché de página), y haz clic en uno para ver sus registros en un panel lateral. Cada máquina en la flota obtiene los mismos controles — registros, iniciar/detener/reiniciar, política de reinicio, fijar — a través de la misma conexión SSH que la sonda ya usa, y toda la pestaña funciona en un teléfono.
- Servicios systemd — locales o remotos, tus propias unidades resaltadas, fallos primero.
- Mapas de árbol de disco estilo WizTree — en cualquier máquina de la flota. Haz clic en las carpetas que llenan un disco en el concentrador o en cualquier host Linux que hayas agregado; un remoto se escanea a través de la misma conexión SSH que usa todo lo demás, así que no hay nada que instalar en él. Además, I/O de red con los principales conversadores por contenedor y un mini-htop para quién está consumiendo CPU y RAM.
- Se mueve como un panel en vivo. La utilización, RAM, temperatura y potencia se actualizan cada par de segundos a través de un flujo push en lugar de un sondeo fijo — y lo hace haciendo menos solicitudes que antes, porque la consulta de historial costosa se obtiene solo tan a menudo como sus propios buckets de gráfico pueden cambiar, y una pestaña que no estás mirando deja de costar nada. La cadencia de muestreo y almacenamiento no se tocan, así que el historial permanece exactamente tan denso (y los costos exactamente tan precisos) como estaban.
- Multi-máquina vía SSH — pega una clave por máquina; Linux, una Pi, incluso Windows. Sin agentes, sin instalaciones. La pestaña GPU también funciona por host: un equipo remoto multi-GPU muestra la VRAM, utilización, potencia y temperatura de cada tarjeta, y los procesos que mantienen la memoria.
- Monitoreo de tiempo de actividad, dentro de la caja — observa cualquier endpoint HTTP o puerto TCP (tus servicios, un NAS, un sitio remoto) directamente desde el contenedor: tira de latidos, % de tiempo de actividad 24h/7d, latencia, y alertas inteligentes por verificación — confirmación anti-rebote, recuperación con tiempo de inactividad, y una advertencia opcional de respuesta lenta. Sin servicio de tiempo de actividad adicional para autoalojar — ya está en la caja.
- Alertas push — Discord, ntfy.sh y Telegram, activadas por borde para que no envíen spam.
Recorrido completo pestaña por pestaña → Características.
Multi-máquina, en dos oraciones
Abre la pestaña Hosts, pega la clave SSH autogenerada del concentrador en cada remoto, y el concentrador comienza a sondearlo — sin agentes, solo SSH + Python 3 (PowerShell en Windows). El concentrador envía una pequeña sonda autocontenida vía SSH; nada persiste en el remoto. La misma conexión es lo que te permite abrir la cabina GPU de un remoto y escanear sus discos desde el concentrador — aún sin nada instalado en el otro extremo.
Incorporación, configuración de Windows y el modelo de seguridad → Documentos multi-máquina.
Configuración
Establece estos bajo environment: en docker-compose.yml (todos opcionales):
| Variable | Predeterminado | Significado |
|---|---|---|
SAMPLE_INTERVAL | 10 | Segundos entre muestras almacenadas. Esta es la cadencia de almacenamiento — cada cifra de energía y costo se integra contra ella, así que cambiarla cambia cómo se calcula el precio del historial |
FAST_INTERVAL | 2 | Segundos entre actualizaciones de valores en vivo en pantalla. Lee solo contadores baratos y no almacena nada, así que no cuesta historial ni precisión. 0 apaga el flujo push y el panel vuelve al sondeo |
RETENTION_DAYS | 180 | Cuánto tiempo se conserva el historial |
PRESSURE_FREE_MB | 2048 | VRAM libre por debajo de esto cuenta como "presión" |
PORT | 9800 | Puerto del panel |
MCP_PORT | 9810 | Puerto para el servidor MCP integrado de solo lectura |
ENABLE_MCP | 1 | Establece 0 para ejecutar el panel sin el servidor MCP |
ENABLE_CONTROLS | 1 | Establece 0 para eliminar los botones iniciar/detener/reiniciar de las pestañas Contenedores y Servicios |
ALLOW_SELF_UPDATE | 1 | Establece 0 para deshabilitar la actualización dentro de la aplicación |
WATCH_CONTAINERS | — | Contenedores adicionales para escanear por OOM (separados por comas) |
WATCH_SERVICES | — | Unidades systemd para mostrar siempre, incluso las del proveedor (separadas por comas) |
CHECK_UPDATES | true | Establece false para deshabilitar la verificación diaria de versiones de GitHub (sin llamadas salientes) |
CHECK_OS_UPDATES | true | Establece false para dejar de reportar actualizaciones de paquetes del SO pendientes |
PUBLIC_STATUS | — | Establece para habilitar la página de estado pública (también un interruptor en Configuración, que no requiere reinicio) |
DB_PATH | /data/gpu.db | Dónde se almacena el historial dentro del contenedor |
HOST_ROOT | /rootfs | Punto de montaje de la raíz del host de solo lectura |
DOCKER_SOCK | /var/run/docker.sock | Socket de Docker para leer contenedores |
El historial vive en ./data/gpu.db (un montaje bind), así que sobrevive reinicios y actualizaciones. Alertas, el montaje D-Bus de systemd y ajustes por servidor → Documentos de configuración.
Bajo el capó
El concentrador une nvidia-smi (más GPU AMD vía la interfaz sysfs amdgpu en el kernel, y AMD/Intel en hosts Windows vía los contadores de rendimiento GPU integrados), la API de Docker, las API de servidores de modelos (Ollama, vLLM, llama.cpp, A1111, …), D-Bus de systemd y /proc + /sys en una vista muestreada, persistida en SQLite y reducida en lectura para que un rango de seis meses cargue tan rápido como la última hora. Página única, Chart.js incluido, sin paso de compilación.
- Más de 30 servidores de modelos reconocidos → Servidores de modelos
- Endpoint
/metricsestándar para extraer a los paneles que ya ejecutas → Exportación de métricas - El pipeline de datos completo + atribución de llamadas → Cómo funciona
Conecta un agente de IA (MCP)
Tu laboratorio doméstico ahora es legible para agentes de IA — apunta un cliente a una URL y puede ver cada host, contenedor, GPU y disco. Solo lectura, sin configuración adicional.
HomeLab Monitor ya no es solo un panel para ti; también es contexto para tu agente de IA. Un servidor MCP de solo lectura está integrado en el mismo contenedor (servido en :9810) — así que Claude, Claude Code o cualquier cliente MCP se conecta en una línea y explora todo tu laboratorio a través de 19 herramientas nombradas, con la misma cobertura que ves en el panel: hosts, contenedores, servicios systemd, GPU y quién la está usando, RAM por proceso, servidores de modelos de IA, modelos instalados, costos, ejecuciones de experimentos, benchmarks de modelos, mapas de árbol de disco, historial y alertas.
Conecta cualquier cliente MCP — Claude, ChatGPT o un agente en tus propios modelos locales de Ollama — y leerá el estado en vivo de tu homelab. Solo lectura: ambas direcciones son solo preguntas y respuestas.
# the dashboard is on :9800; the MCP server rides along on :9810
claude mcp add --transport http homelab http://YOUR-HUB:9810/mcp
Una vez conectado, olvídate de buscar entre pestañas y simplemente pregunta — el agente elige las herramientas adecuadas:
- "Mi GPU ha estado al máximo durante una hora — ¿qué servidor de modelos está cargado y quién lo está usando realmente?"
- "¿Qué está consumiendo
/backup? Dame las carpetas más grandes y marca cualquier cosa que parezcan registros descontrolados." - "¿Qué host tiene menos RAM ahora mismo y cuál es el proceso principal que la está usando?"
- "Quiero reiniciar y hacer una actualización del sistema este fin de semana — ¿qué equipo lo necesita más y cuál es un orden seguro según lo que está ejecutando cada uno?"
Solo lectura por diseño — no hay herramientas de escritura, así que un agente puede mirar pero nunca tocar tu flota. Apágalo cuando quieras con ENABLE_MCP=0. Lista completa de herramientas y configuración → Documentación de MCP.
Seguridad
Este es un monitor de host: se ejecuta con acceso al host, además de un socket Docker de lectura-escritura y un socket D-Bus (la autoactualización y los controles de iniciar/detener/reiniciar de las pestañas Contenedores/Servicios están activados por defecto — configura ALLOW_SELF_UPDATE=0/ENABLE_CONTROLS=0, o usa docker-compose.readonly.yml, para restringirlo a monitoreo puro) y un montaje raíz de solo lectura — una superficie amplia por diseño. El panel en sí no tiene inicio de sesión/autenticación — está pensado para una LAN de confianza. Mantenlo detrás de tu LAN/VPN/cortafuegos y no lo expongas a internet público. Detalles → documentación.
⭐ Apoya el proyecto
Si HomeLab Monitor te ahorra una o dos pestañas del navegador, una ⭐ en GitHub realmente ayuda a que otros entusiastas del homelab lo encuentren. ¡Gracias!
💬 Comunidad
Construir esto es más divertido juntos. Únete al Discord de HomeLab Monitor — saluda, presume tu equipo, intercambia ideas, pide ayuda o simplemente pasa el rato. Es donde ocurren las conversaciones sobre la hoja de ruta, las preguntas de "¿deberíamos construir X?" y la ayuda rápida — y donde los nuevos colaboradores reciben una cálida bienvenida.
Trae a un amigo, publica una idea, abre un issue — hagamos crecer una comunidad de homelab amigable y saludable. 💛
Contribuciones
Los issues y PRs son muy bienvenidos — especialmente nuevas sondas de servidores de modelos, nuevos monitores y back-ends de GPU. Esta es una herramienta de hobby pensada para ayudar a otros entusiastas del homelab, así que sé amable. Consulta CONTRIBUTING.md.
Colaboradores
Gracias a todos los que han abierto un issue, enviado un PR o ayudado a dar forma a la hoja de ruta. Todo el back-end de GPU AMD — VRAM por proceso mediante DRM fdinfo y paridad completa del panel en v0.28.0, VRAM real en APUs de memoria unificada en v0.26.0 — vino de @andreahaku. El registro de modelos consciente de la flota de v0.27.0 y las ventanas de mantenimiento de v0.23.0 vinieron de @1HazyOne707. La potencia RAPL de CPU/DRAM de v0.27.0 y la refactorización del árbol de módulos backend/ de v0.24.0 vinieron de @pehota. Consulta el registro de cambios para ver el historial completo de créditos en curso.
Licencia
MIT — consulta LICENCIA.