Hay un problema que aparece tarde o temprano cuando llevas un tiempo con el homelab: necesitas almacenamiento de objetos compatible con S3. No porque seas Amazon, sino porque muchas herramientas modernas hablan S3 de forma nativa. Velero para backups de Kubernetes. Loki para logs. Restic, Rclone, Backblaze. Incluso algunas aplicaciones como Immich o Seafile pueden usar S3 como backend.
Si dependes de AWS S3 real, tienes un coste mensual variable y tus datos en manos de Amazon. MinIO resuelve eso: un servidor de objetos que habla la misma API que S3, que corres en tu propio hardware.
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.
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.
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.
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í.
Durante años guardé recetas como marcadores de Chrome. Luego en Notion. Luego en una carpeta de Obsidian. Ninguno funcionó bien. Mealie sí. Te cuento cómo lo monté y qué hace que marque la diferencia.
Llevo tres años gestionando clusters Kubernetes. He aprendido kubectl, helm, kustomize, escribo YAMLs dormido, y aun así… hay días que abro Rancher y respiro tranquilo. Porque sí, kubectl es potente y la terminal mola. Pero cuando son las 3 de la mañana y algo se ha caído, ver gráficos de CPU en vez de piped JSON es la diferencia entre arreglarlo en 5 minutos o perder una hora.
Rancher no te convierte en peor administrador de Kubernetes. Te convierte en uno más eficiente. Y eso es lo que vamos a montar hoy.
Soy de esas personas que tiene 40 containers corriendo en producción y cada vez que veo un “new image available” me da pereza actualizar. No porque sea difícil, sino porque son 40. Y algunos necesitan recrear el stack completo. Y otros dependen de otros. Y siempre hay uno que se rompe al actualizar.
Watchtower resolvió este problema por mi. Ahora mis containers se actualizan solos, de noche, sin que yo toque nada. Y cuando algo se rompe (porque siempre se rompe algo), tengo rollback automático.
Llevo casi dos años con Home Assistant corriendo en mi homelab y es una de las cosas que más uso cada día. No es la instalación más compleja que tengo (ese premio se lo lleva el cluster de Kubernetes), pero es la que más impacto tiene en mi vida diaria.
La diferencia entre tener cacharros “inteligentes” sueltos por casa y tener Home Assistant es brutal. Pasas de 47 apps diferentes que medio funcionan a tener todo en un solo sitio. Y lo mejor: cuando Philips o Samsung decidan que tu bombilla o tu enchufe “ya no son compatibles”, te da igual. Home Assistant seguirá funcionando.
Tengo un problema. Mejor dicho, tenía un problema.
Después de dos años montando servicios en mi homelab, llegué a un punto donde tenía 43 containers Docker corriendo entre tres servidores diferentes. Plex, Grafana, n8n, Gitea, Vaultwarden, Home Assistant… la lista seguía y seguía.
El problema no era Docker. Docker funciona de puta madre. El problema era yo, intentando recordar qué compose file iba con qué servicio, en qué puerto corría cada cosa, y por qué narices ese container se reiniciaba cada 15 minutos.
Tenía 12 servicios corriendo en Phatt, cada uno en su puerto raro. Acceder a ellos era recordar que Grafana está en el 3000, n8n en el 5678, Gitea en el 3001… Traefik lo cambió todo: subdominio propio, HTTPS automático, y si añado un nuevo contenedor solo pongo dos etiquetas.