Durante mucho tiempo mi stack de monitorización fue Grafana más Prometheus más node_exporter más varios exporters específicos. Funciona bien, da dashboards muy potentes, y lo recomiendo. También tarda horas en configurar correctamente, tiene un consumo de recursos no despreciable, y cualquier nueva métrica que quieras monitorizar requiere buscar el exporter adecuado, configurarlo, añadir el scrape job en Prometheus, crear el panel en Grafana.
Netdata tiene una filosofía diferente. Instalas el agente y en dos minutos tienes datos de todo: CPU, memoria, disco, red, procesos, temperatura, Docker, y decenas de integraciones que se detectan automáticamente. Sin tocar ningún archivo de configuración en la instalación básica.
Tengo más SBCs repartidos por casa de lo que me gustaría admitir. Hay un par de Raspberry Pi haciendo de sensores, un ZimaBoard en el rack de red, y algún Orange Pi que empecé a usar para algo y se quedó a medias. Todos estuvieron durante meses sin carcasa, apoyados sobre su propia PCB o dentro de bolsas antiestáticas. Funciona, pero es feo y no protege nada.
La impresora 3D cambió eso. Ahora cada SBC que uso tiene su carcasa impresa, con ventilación, con soporte para el rack si hace falta, y en algunos casos con personalización que no encontrarías en ningún sitio. Llevarlo a la práctica no es complicado, pero hay decisiones de material y de diseño que marcan la diferencia entre una carcasa que dura y una que se deforma al mes.
Este no es un post de teoría sobre IA. Es lo que realmente tengo montado, lo que ha funcionado, lo que no, y por qué creo que la forma en que muchas empresas están aproximándose a los agentes de IA está mal planteada.
Contexto: gestiono la distribución de varias marcas de cosmética de lujo en España. Marcas con catálogos grandes (cientos de productos), terminología muy específica (ingredientes activos, protocolos de tratamiento, formaciones de terapeuta), y materiales que constantemente hay que adaptar: manuales, fichas de producto, presentaciones para clientes, contenido para redes sociales.
Llevo años peleándome con scrapers que fallan en la mitad de las webs. Curl y wget para páginas estáticas, Playwright para las que necesitan JavaScript, Selenium para las que son especialmente cabronas… y siempre el mismo problema: login. Si la página necesita que estés autenticado, la cosa se complica bastante.
La semana pasada instalé browser-use CLI y cambió bastante el panorama. No es magia, pero es la herramienta más práctica que he encontrado para automatizar el navegador desde la terminal de una forma sencilla y que además puede usar tus sesiones reales de Chrome. Sin configurar credenciales. Sin gestionar cookies manualmente.
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.