Cómo terminé montando un homelab híbrido entre Hetzner y mi casa
Llevo desde principios de 2026 con un pie en Hetzner y otro en casa, y en algún punto dejé de pensarlo como “un servidor en la nube” y “un NAS en casa” por separado, para verlo como una sola infraestructura repartida en dos sitios. Esto es la historia de cómo llegué ahí, con los golpes incluidos.
¿Qué es un homelab híbrido?
Es, sencillamente, tu laboratorio personal partido entre hardware que controlas físicamente en casa y cómputo que alquilas en un datacenter, unidos por una red privada como si fueran una sola LAN. No es “tener un VPS” ni “tener un NAS”: es que ambos mundos se hablan entre sí, comparten direccionamiento, y las cargas se colocan donde tiene más sentido cada una.
En mi caso el “datacenter” es Hetzner y la “casa” es, literalmente, mi casa.
Cómo empezó: un MicroK8s que se quedó corto
Empecé con algo modesto: un par de nodos en Hetzner corriendo MicroK8s. Ahí sigue viviendo hoy mi gateway personal de MCP, el que le da a Claude acceso a mis herramientas de trabajo y de homelab. Ese clúster nunca me dio problemas, hacía justo lo que le pedía.
El problema fue que, una vez tienes un pie en un datacenter, es muy fácil querer meter el otro más adentro. Quise dar el salto a algo más ambicioso: un lab de OpenShift “solo para jugar”, con un clúster compacto real en vez de la versión de un solo nodo. Compré un servidor de segunda mano (lo que Hetzner llama Server Auction) e instalé ESXi para montar vCenter y, encima, OpenShift.
La saga de meterle OpenShift
Ahí es donde el homelab híbrido deja de ser una idea bonita y se convierte en resolver problemas de red uno detrás de otro. Algunos de los que más me costaron:
- El instalador de ESXi solo detectaba mi disco si lo emulaba de una forma muy concreta, y tuve que instalar en un modo de arranque más antiguo para que coincidiera con cómo arranca el propio servidor.
- La red privada de Hetzner usa paquetes un poco más pequeños de lo normal: si no lo replicas en tus máquinas virtuales, todo parece funcionar (el DHCP va bien) hasta que mandas algo de tráfico “grande” y se corta de forma rarísima.
- Hetzner bloquea las consultas DNS hacia servidores externos como medida antiabuso, así que tienes que resolver contra los suyos, algo que no se te ocurre revisar hasta que llevas media tarde con “esto no resuelve”.
- Tuve una asimetría de tráfico entre mis máquinas y mi VPN que mi firewall descartaba en silencio: el ping funcionaba, pero cualquier conexión de verdad se quedaba a medias. Tardé bastante en diagnosticarlo con capturas de paquetes.
- Cuando añadí un segundo servidor para hacer el clúster más real, descubrí que tenía muchísima latencia hacia el primero, pese a estar, en teoría, en el mismo datacenter. Inviable para lo que quería montar encima.
Nada de esto es exótico si te dedicas a esto de forma profesional. Pero una cosa es leerlo en un manual y otra muy distinta es perseguirlo a las once de la noche en tu propio proyecto, sin nadie a quien escalarle el ticket.
El replanteo: ¿un host más grande o llevar mi propio hardware?
Ese problema de latencia entre servidores me hizo parar y replantear la arquitectura. Sobre la mesa tenía dos caminos “grandes”: meter todo el clúster en un único servidor más potente, o dar un paso más ambicioso todavía: llevar mi propio hardware a un rack de Hetzner (colocation) y tener control total de mi red en vez de estar peleando con la suya. Resulta que en casa tengo guardado un firewall de nivel empresarial y un servidor viejo que llevaban tiempo sin usarse, así que la opción de colocation dejó de sonar descabellada.
Dónde quedó la cosa: la versión corta
Al final no elegí ninguno de los dos caminos “grandes”. Le di vueltas, y me di cuenta de que el lab de OpenShift era, sobre todo, un ejercicio de aprendizaje, y ya me había dejado el aprendizaje que buscaba. Mantenerlo con hardware propio o colocation era resolver un problema que ya no tenía: no necesitaba un clúster de OpenShift corriendo 24/7 para nada real.
Así que simplifiqué, mucho. Hoy todo mi homelab en Hetzner vive en 5 máquinas virtuales de Cloud, nada de servidores dedicados ni ESXi:
- 2 nodos de Kubernetes (MicroK8s), ahí vive el gateway de MCP y lo que necesito con orquestación real.
- 1 VM de VPN, el punto donde se conecta el túnel WireGuard con mi casa.
- 1 VM de Servicios, todo lo que corre suelto en Docker Compose, sin necesitar K8s.
- 1 VM de Bases de datos, MySQL y Postgres, separadas del resto para no mezclar estado con cómputo.
Una estimación aproximada de lo que cuesta mantener estas 5 VMs con los precios de Hetzner Cloud de 2026 (tamaños moderados, ajusta según lo que le des tú a cada una):
| VM | Función | Coste aproximado/mes |
|---|---|---|
| Nodo K8s 1 | MicroK8s: orquestación, gateway de MCP | ~10–12 € |
| Nodo K8s 2 | MicroK8s: orquestación, gateway de MCP | ~10–12 € |
| VPN | WireGuard site-to-site con casa | ~4–6 € |
| Servicios | Docker Compose: servicios sueltos | ~18–22 € |
| Bases de datos | MySQL + Postgres | ~18–22 € |
| Total aproximado | ~60–75 €/mes |
Nada que ver con los ~120 €/mes que llegué a tener entre los dos servidores de subasta del lab de OpenShift, y sin ninguno de los dolores de cabeza de ESXi, vCenter o MTUs de hipervisor. A veces la mejor decisión de arquitectura es simplemente dejar de sobre-ingenierizar.
En un próximo post cuento cómo quedó todo técnicamente: el diagrama de cómo se conecta cada pieza con mi red de casa, y el desglose completo de precios.

[…] el post anterior conté la historia de cómo terminé con un homelab híbrido entre Hetzner y mi casa, y por qué […]