Homelab con Docker Compose sin Kubernetes en 2026
Pete Keen reconstruyó su homelab con Docker Compose, Ruby e IPv6, y sacó Kubernetes de la ecuación. En un posteo actualizado el 10 de julio de 2026, contó cómo pasó de un clúster improvisado y medio caído a un stack simple que corre en una sola máquina sobrada. La conclusión es clara: para la mayoría de los homelabs, un homelab con Docker Compose alcanza y sobra.
Un homelab con Docker Compose es un servidor casero donde cada servicio se define en un archivo compose.yml y Docker levanta todo con un solo comando. No hay orquestador de clúster, ni control plane, ni nodos: una máquina, contenedores declarados en YAML, y redes internas entre ellos. Es el enfoque más común para laboratorios de una o dos máquinas.
En 30 segundos
- Kubernetes es opcional en casa. Keen lo pausó y no lo extrañó; Compose cubre lo que un homelab necesita.
- Una máquina bien equipada gana a un clúster frágil. Su servidor sobreviviente es un Lenovo M80s Gen3 con i7-12700, 128GB DDR5 y 3TB NVMe.
- El almacenamiento va aparte. Sumó una HBA con un disk shelf de siete discos de 16TB (112TB brutos).
- IPv6 simplifica exponer servicios sin tanto reverse proxy ni port forwarding.
- Lo que perdés con Compose es auto-recuperación de nodos. En un homelab, casi nunca la necesitás.
¿Cuándo Docker Compose es mejor que Kubernetes en un homelab?
Ponele que querés correr Jellyfin, un Pi-hole y un Gitea en casa. ¿Necesitás Kubernetes para eso? No.
Kubernetes resuelve un problema que casi ningún homelab tiene: coordinar decenas de servicios sobre muchos nodos, con reprogramación automática cuando una máquina se cae. Eso es oro en producción con SLAs. En tu sótano, es un peso muerto operativo que te come tardes enteras (spoiler: el clúster de Keen quedó en pausa justamente por eso).
La regla práctica es simple. Si tenés una o dos máquinas y podés tolerar que un servicio esté caído diez minutos mientras lo reiniciás, Compose es la respuesta. Si de verdad necesitás alta disponibilidad real, con failover automático entre nodos físicos, y tenés al menos tres máquinas para hacerlo bien, ahí sí Kubernetes (o algo liviano como k3s) empieza a justificarse.
El tema es que mucha gente arranca con K8s por currículum, no por necesidad. Y termina administrando el orquestador en vez de usar sus servicios. Tema relacionado: integrar pipelines CI/CD automáticos.
Requisitos de hardware recomendados para un homelab funcional
Acá viene lo bueno: no necesitás un rack. Necesitás una máquina decente.
El caso de Keen lo muestra bien. Su servidor sobreviviente, al que llama Nibbler, es un Lenovo M80s Gen3 SFF con un i7-12700 y memoria DDR5, comprado usado en eBay por lo que describe como una ganga. Le puso 128GB de RAM y 3TB de NVMe. Después le agregó una HBA y colgó un disk shelf con siete discos de 16TB. O sea: un mini-Pc de oficina convertido en el corazón de todo el laboratorio.
La lección es que las máquinas refurbished corporativas (esos SFF de Lenovo, Dell o HP que las empresas rematan por lote) son la mejor relación precio/potencia para empezar. Silenciosas, chicas, con soporte de RAM y NVMe de sobra.
Guía mínima según lo que quieras correr:
- Homelab básico (DNS, reverse proxy, un par de apps): 4 núcleos, 16GB RAM, 500GB SSD. Un mini-PC usado zafa.
- Homelab medio (media server, self-hosting, monitoreo): 6 a 8 núcleos, 32 a 64GB RAM, 1 a 2TB NVMe.
- Homelab pesado (transcoding, muchos discos, VMs): i7/Ryzen 7, 128GB RAM, NVMe para sistema y HBA con discos grandes para datos, tal cual el setup de Keen.
Sobre el ROI frente a un VPS: alquilar cómputo tiene sentido para cosas que necesitan estar online 24/7 con IP pública estable. Para eso, un plan de hosting o VPS en donweb.com te evita el dolor de cabeza de la IP dinámica y el uptime casero. Pero si tu objetivo es almacenamiento masivo y experimentar, el fierro propio se amortiza rápido (112TB brutos en la nube salen una fortuna todos los meses).
¿Cómo estructurar Docker Compose para múltiples servicios?
La primera decisión: ¿un solo compose.yml gigante o varios archivos?
Para pocos servicios, un archivo único alcanza. Cuando la cosa crece, conviene un archivo por stack (uno para media, otro para monitoreo, otro para la web), cada uno en su carpeta, con su propio .env. Así reiniciás Jellyfin sin tocar Prometheus.
Los puntos que no podés saltear:
- Redes internas explícitas. Declará una red por stack. Los contenedores se hablan por nombre de servicio (
http://gitea:3000), no por IP. - Volúmenes persistentes siempre. Todo lo que sea data va a un volumen o a un bind mount fuera del contenedor. Si borrás el contenedor, la data queda.
- Secrets fuera del YAML. Usá
.envo Docker secrets, nunca hardcodees tokens en el compose. Y ese.envjamás va al repo. - Backups reales. Un cron que copie los volúmenes a otro disco (o al disk shelf). Compose no te hace backup solo.
Un stack mínimo viable arranca con tres piezas: un reverse proxy (Traefik o Caddy) al frente, un servidor DNS interno, y una app de prueba detrás. Con eso ya tenés HTTPS automático y ruteo por subdominio.
IPv6 en homelabs: por qué conviene en 2026
¿Por qué Keen se tomó el trabajo de meter IPv6? Porque te da direcciones públicas de verdad para cada servicio, sin pelearte con el NAT.
Con IPv4 en casa estás detrás de una sola IP pública (cuando la tenés), haciendo malabares con port forwarding y un reverse proxy que multiplexa todo por el puerto 443. Con IPv6, cada contenedor puede tener su propia dirección global y ruteable. Exponés el servicio directo, con su firewall, sin abrir puertos a mano. Relacionado: desplegar con Jenkins en tu homelab.
El detalle argentino: no todos los ISP entregan IPv6 nativo, y los que lo hacen a veces dan un prefijo raro o cambian el rango delegado. Antes de armar todo, verificá qué prefijo te asigna tu proveedor (un /56 o /48 es lo ideal). Sin prefijo estable, la fiesta dura poco.
En Docker, IPv6 se activa en el daemon y después declarás dual-stack en la red del compose. Ojo: es de las features que más cambió entre versiones de Docker, así que revisá la config para tu versión antes de asumir que anda.
Servicios esenciales para un homelab moderno sin Kubernetes
Estos son los sospechosos de siempre, agrupados por para qué sirven. Todos corren en docker-compose.yml sin drama.
Puerta de entrada: reverse proxy
Traefik o Caddy. Reciben todo el tráfico, resuelven certificados Let’s Encrypt solos y rutean por subdominio a cada contenedor. Caddy es más simple de configurar; Traefik descubre servicios por labels de Docker.
DNS y bloqueo de ads
Pi-hole. Hace de DNS interno para toda la casa y de paso filtra publicidad y trackers. Un contenedor, config mínima, impacto inmediato en cada dispositivo.
Media
Jellyfin. Servidor de películas, series y música, open source y sin suscripción. Acá es donde el i7-12700 de Keen gana el sueldo: el transcoding en vivo pide CPU (o una iGPU que lo acelere). Esto se conecta con lo que analizamos en ejecutar agentes sin APIs externas.
Git propio
Gitea. Un GitHub personal en 200MB de RAM. Ideal para tus repos privados y para practicar CI casero.
Monitoreo
Prometheus más Grafana. Prometheus junta métricas, Grafana las dibuja. Con esto ves cuánta RAM te queda antes de que se caiga algo (que es justo el dato que faltaba cuando se murió una máquina de Keen).
Migración de Kubernetes a Docker Compose: paso a paso
Si venís de un clúster K8s que se volvió inmanejable (como le pasó a Keen), el camino de vuelta es más fácil de lo que parece.
La traducción conceptual es directa: un Pod pasa a ser un contenedor o un grupo de servicios en el mismo compose; los Services de K8s se reemplazan por la red interna de Compose y el DNS por nombre; los PersistentVolumes se vuelven volúmenes de Docker; los ConfigMaps y Secrets pasan a .env y Docker secrets.
El proceso, sin vueltas:
- Listá tus workloads. Un Deployment de K8s por lo general es un solo servicio en Compose.
- Traducí cada manifiesto. Imagen, puertos, variables y volúmenes de cada Deployment van a un bloque
services:. - Reemplazá los Services por la red de Compose. Las llamadas internas pasan a usar el nombre del servicio.
- Migrá la data. Copiá el contenido de cada PersistentVolume al volumen nuevo antes de apagar el clúster.
- Probá y apagá K8s. Levantá el compose, verificá, y recién ahí desmantelás el control plane.
¿Qué ganás? Menos piezas móviles y arranques instantáneos. ¿Qué perdés? El scheduling automático entre nodos. En una sola máquina, eso no existía igual.
| Aspecto | Docker Compose | Kubernetes |
|---|---|---|
| Curva de aprendizaje | Baja (un YAML) | Alta (muchos objetos) |
| Máquinas ideales | 1 a 2 | 3 o más |
| Auto-recuperación entre nodos | No | Sí |
| Reinicio de contenedor caído | Sí (restart policy) | Sí |
| Overhead operativo | Mínimo | Alto |
| Cuándo elegirlo | Homelab, apps chicas | Producción con HA real |
Monitoreo y mantenimiento sin orquestación automática
Acá está la letra chica de Compose: si un servicio se cae de madrugada, nadie lo levanta por vos. No hay un scheduler vigilando. Pero eso se compensa con dos cosas baratas. Para más detalles técnicos, mirá proteger tu infraestructura privada.
Primero, las restart policies. Poné restart: unless-stopped en cada servicio y Docker reinicia el contenedor si se muere. No cubre una caída de toda la máquina, pero sí el 90% de los cuelgues cotidianos.
Segundo, los health checks. Compose los soporta: definís un comando que chequea si el servicio responde y Docker marca el contenedor como unhealthy si falla. Combinado con un contenedor tipo Autoheal, reiniciás lo que quedó zombie.
Para el resto, un poco de pegamento casero: Grafana con alertas a Telegram o mail cuando la RAM o el disco pasan un umbral, y logs centralizados con Loki o simplemente docker compose logs. ¿Es tan robusto como K8s? No. ¿Importa en tu sótano? Casi nunca.
Errores comunes al armar un homelab con Docker Compose
- Guardar la data adentro del contenedor. Un día lo recreás para actualizar la imagen y perdés todo. Corrección: volúmenes o bind mounts para cada dato persistente, siempre.
- Commitear el
.envcon secrets. Tokens y contraseñas terminan en el repo (y en internet si es público). Corrección:.enven el.gitignoredesde el primer commit. - Exponer puertos de más. Mapear
5432:5432de Postgres al host cuando solo lo usa otro contenedor. Corrección: si el servicio es interno, no publiques el puerto; que se hablen por la red de Compose. - Asumir que IPv6 anda igual en toda versión de Docker. Copiás una config vieja y no levanta. Corrección: verificá la sintaxis para tu versión de Docker antes de pelearte con el firewall.
Preguntas Frecuentes
¿Por qué abandonar Kubernetes en un homelab casero?
Porque Kubernetes resuelve alta disponibilidad entre muchos nodos, un problema que un homelab de una o dos máquinas no tiene. Su overhead operativo (control plane, networking, mantenimiento) no se justifica cuando podés tolerar reinicios manuales. Pete Keen pausó su clúster y migró todo a Docker Compose sin extrañarlo.
¿Cuál es el hardware mínimo para un homelab con Docker Compose?
Para un setup básico alcanza con 4 núcleos, 16GB de RAM y un SSD de 500GB, algo que cubre un mini-PC corporativo usado. Para media server y monitoreo, apuntá a 32-64GB de RAM y NVMe. El servidor de referencia de Keen es un Lenovo M80s Gen3 con i7-12700 y 128GB DDR5.
¿Qué ventaja da IPv6 en un homelab?
IPv6 le da a cada contenedor una dirección pública ruteable, así exponés servicios sin NAT ni port forwarding. Simplifica la red y elimina el cuello de botella de tener una sola IPv4 pública. La contra en Argentina es que no todos los ISP entregan un prefijo IPv6 estable.
¿Cómo migro mis manifiestos de Kubernetes a Docker Compose?
Cada Deployment se traduce a un bloque services: con imagen, puertos, variables y volúmenes. Los Services de K8s se reemplazan por la red interna de Compose y el DNS por nombre de contenedor. Migrá la data de cada PersistentVolume antes de apagar el control plane.
¿Qué se pierde al usar Compose en vez de Kubernetes?
Se pierde la reprogramación automática de workloads entre nodos físicos: si se muere una máquina, Compose no reubica los servicios solo. En una sola máquina esa función no aplicaba igual, y las restart policies más los health checks cubren la mayoría de los cuelgues cotidianos.
Conclusión
La historia de Keen es una vacuna contra el sobrediseño. Empezó con un clúster ambicioso, se le rompió media infraestructura, y terminó más contento con una máquina sobrada corriendo Docker Compose. El mensaje para cualquiera que arranca: elegí la complejidad que tu problema pide, no la que suena impresionante.
Si estás armando tu laboratorio hoy, hacé esto: conseguí un mini-PC corporativo usado, ponele RAM y NVMe, definí tus servicios en un compose.yml, sumá restart policies y un Grafana con alertas. Cuando de verdad necesites tres nodos con failover automático, ahí evaluás Kubernetes. Antes, no.
