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.
Llevo tres semanas usando Nextcloud como mi única nube. Sin Google Drive, sin OneDrive, sin depender de nadie para mis archivos. Y no voy a mentir: esperaba más problemas de los que tuve.
La idea me rondaba desde hace meses. Tengo un NAS en casa, capacidad de sobra, y me molestaba pagar por almacenamiento cuando tengo 10TB sentados ahí sin hacer nada útil. Pero siempre había algo que me frenaba. La sincronización móvil me daba miedo. Los conflictos de archivos. Que se cayera cuando estuviera fuera de casa.
En el post sobre Ollama expliqué cómo montar modelos de lenguaje en local. Lo que no conté es que usar Ollama directamente por terminal tiene sus limitaciones. Funciona, pero no es cómodo para el uso diario.
Open WebUI resuelve eso. Es una interfaz web para Ollama que se parece mucho a ChatGPT en apariencia y funcionalidad, pero corre en tu propia red, sin enviar datos a nadie, y sin límites de uso.
Llevo dos años pagando GitHub Pro. 4$ al mes. No es mucho dinero pero me molestaba. No porque sea caro, sino porque estaba pagando por algo que podía tener en mi homelab. Repos privados ilimitados, CI/CD, wikis, issues… todo corriendo en 200MB de RAM.
En diciembre monté Gitea y migré todos mis repos. No he vuelto a GitHub para proyectos personales.
Por qué self-hostear Git # GitHub está bien. Es rápido, fiable, todo el mundo lo conoce. Pero tiene varios problemas si trabajas en proyectos personales o internos de empresa:
Llevaba tiempo con Portainer en Phatt. Funciona, nadie puede decir que no funciona. Pero tiene una cosa que me molestaba: cada vez que quiero desplegar algo nuevo, hay demasiado click-click para configurar volúmenes, redes, variables de entorno. No es ágil.
Coolify lo probé también. Muy orientado a aplicaciones web con git deploy, casi demasiado para lo que hago en el homelab. Y el proceso de instalación me dejó una sensación de “esto es grande para lo que necesito”.
n8n es la herramienta de automatización que tenía que haber instalado antes. Sin código, self-hosted y con 400 integraciones. Aquí están los flujos que uso de verdad en mi homelab.
Llevo un año con Grafana y Prometheus corriendo en mi homelab y es probablemente una de las cosas que más uso a diario. No porque sea bonito (que lo es), sino porque me he ahorrado un montón de problemas al ver las cosas antes de que exploten.
Te cuento cómo lo tengo montado, qué métricas vigilo, y sobre todo, los errores que cometí para que tú no los repitas.
Por qué necesitas monitorización en tu homelab # Mira, cuando empecé con el homelab solo tenía un mini PC con Docker. Sabía si algo iba mal porque dejaba de funcionar. Directo, efectivo, cero métricas.
He cometido el error dos veces ya. Montar algo “rapidito” en Docker Compose, que crece, se complica, y termino pasándolo a Kubernetes porque ya no puedo gestionarlo. Luego está el error contrario: montar un cluster K3s completo para hostear un solo contenedor que perfectamente podría vivir en un docker-compose.yml de tres líneas.
Después de gestionar ambos sistemas durante años en mi homelab (ahora mismo tengo varios equipos con Compose y un cluster K3s de tres nodos en ZimaBoard 2), creo que finalmente entiendo cuándo usar cada uno. Spoiler: no es solo “Compose para cosas simples, Kubernetes para lo complejo”. Es más sutil que eso.
