Antes de Uptime Kuma, mi sistema de monitorización consistía en abrir el navegador, escribir la IP de cada servicio y ver si respondía. Funciona, pero está lejos de ser un sistema. Un día me enteré de que un servicio llevaba 14 horas caído porque nadie (yo incluido) lo había comprobado manualmente en ese tiempo.
Eso fue hace dos años. Desde entonces tengo Uptime Kuma corriendo en el homelab y me avisa antes de que yo me dé cuenta de que algo falla. Con cuarenta y tantos monitores configurados, es el servicio que más uso en el día a día aunque sea el que menos veo, precisamente porque cuando funciona bien no necesita atención.
Llevo un par de años imprimiendo piezas que otros diseñaron. Gridfinity, soportes para servidores, cubiertas para la Raspberry Pi… todo genial, pero siempre llegaba el momento en que necesitaba algo específico y no lo encontraba en Printables ni en Thingiverse. O lo encontraba, pero con las dimensiones equivocadas para mi caso concreto.
El salto a diseñar mis propias piezas lo di por necesidad. Tenía un mini PC que necesitaba un soporte que se enganchara al lateral del rack, con unas medidas muy concretas. Nada encajaba. Así que abrí Fusion 360 por primera vez, vi la interfaz y cerré el programa a los diez minutos. Demasiado.
Perdí tres meses de trabajo una vez. No en un homelab, en un servidor de producción, pero la lección se me quedó grabada. Desde entonces tengo una regla no negociable: si no hay backup verificado, no existe.
Durante mucho tiempo usé las snapshots de Proxmox como backup. Es cómodo y rápido, pero es una trampa. Las snapshots viven en el mismo almacenamiento que las VMs. Si falla el disco, pierdes las VMs y las snapshots de golpe. Eso no es un backup, es una ilusión de seguridad.
Durante mucho tiempo pensé que los racks de 19 pulgadas eran la única solución seria para organizar un homelab. Luego miré los precios. Un rack de pared de 6U de marca decente ronda los 80-120 euros, los panels ciegos son absurdamente caros para lo que son, y los soportes específicos para mini PCs o SBCs te los inventas tú porque nadie los fabrica.
O te los imprimes.
Hace dos años tenía mi homelab montado en dos estantes de madera de Ikea. Los Minisforum apilados con separadores de goma. Los ZimaBoard colgando de sus propios cables. Un Switch TP-Link en equilibrio sobre lo que pillase. Funcionaba, pero era un desastre visual y también práctico, porque cuando tenía que revisar algo físicamente perdía cinco minutos identificando qué cable iba a qué máquina.
Hay tareas en el homelab que hago todos los días sin pensar. O las hacía, antes de delegarlas a cron.
Backups nocturnos. Limpiar logs que se acumulan. Revisar si un servicio cayó. Regenerar un reporte de consumo. Actualizar un archivo de configuración. Cosas que si las hago manualmente están bien, pero que si me olvido durante dos semanas empiezan a causar problemas.
Cron lleva décadas siendo la solución estándar en Linux para esto. No es glamuroso. No tiene interfaz web bonita ni métricas en tiempo real. Pero funciona. Cuando llevo meses con un cron job sin tocarlo y sé que está haciendo su trabajo cada día, eso vale mucho.
Si llevas tiempo con el homelab, en algún momento llegaste al punto donde tienes cinco o seis servicios corriendo y necesitas acceder a todos por nombre de dominio en vez de por IP y puerto. Ahí es donde entra el reverse proxy.
Los dos más populares son Nginx Proxy Manager y Traefik. Los he usado los dos en producción, en momentos distintos de la vida de mi homelab, y tengo opiniones formadas sobre cuándo usar cada uno.
Antes de comprar la Prusa Core One, pasé semanas mirando la Bambu Lab A1. Casi la compro. Al final no lo hice, pero no porque la Bambu sea mala, sino porque mis prioridades eran distintas a las de mucha gente. Desde entonces he tenido oportunidad de comparar las dos de cerca y puedo contarte lo que realmente diferencia a una de la otra.
Si estás en el dilema típico de 2026, “Bambu o Prusa”, este artículo es lo que yo habría querido leer antes de decidir.
Uso GitHub Actions con runners propios para automatizar deploys en mi homelab. Cuando hago push a un repo, la nueva versión está desplegada en minutos sin que tenga que hacer nada. Te enseño cómo lo tengo montado.
Llevo meses usando Klipper en vez del firmware de fábrica. La diferencia en calidad de impresión y velocidad es real. Te cuento el proceso de instalación, qué ganás y qué perdes.
Antes de tener OctoPrint, mi relación con la impresora 3D era físicamente exigente. Copiar el archivo en una tarjeta SD, llevarla a la impresora, insertarla, navegar los menús con la ruedecita, iniciar la impresión, y quedarte cerca por si algo iba mal. Si necesitabas cancelar o ajustar algo, tenías que ir hasta la máquina.
Ahora inicio impresiones desde el sofá, veo la webcam en tiempo real, recibo notificaciones cuando algo falla, y el historial de impresiones está en un servidor de mi red local. Eso es lo que hace OctoPrint.
Pasé dos años muy tranquilo con Pi-hole. Funcionaba, bloqueaba anuncios, tenía buenas listas comunitarias y no me daba problemas. Pero hace unos seis meses, mientras reorganizaba mi stack de red, decidí probar AdGuard Home “por curiosidad”. Ese “por curiosidad” lleva seis meses funcionando en producción y Pi-hole lleva seis meses sin arrancar.
Esta no es una entrada sobre que Pi-hole sea malo. Es sobre que AdGuard Home encaja mejor en mi caso concreto, por razones específicas que intento explicar aquí.
Un agente de IA que monitoriza tu infraestructura, revisa el email y ejecuta comandos en tu clúster K3s. Sin SaaS, sin datos que salen de tu red. Esto es lo que monté y lo que aprendí tras meses usándolo.
