Mi homelab con Proxmox: cluster de 4 nodos, Mikrotik, Cloudflare Tunnel y backups con PBS

Un homelab no tiene por qué ser un museo de hardware viejo ni un datacenter improvisado. En mi caso, la meta era distinta: necesitaba un entorno que me permitiera trabajar sin depender de servicios externos, probar ideas antes de llevarlas a clientes y ejecutar cargas que requieren más que un computador personal. Todo sin ruidos, sin consumo exagerado y sin abrir puertas innecesarias a Internet.

Con esos requisitos terminé construyendo un entorno basado en Proxmox VE, cuatro nodos heterogéneos, una red segmentada sobre Mikrotik HAP ac3, acceso remoto únicamente a través de Cloudflare Tunnel y un esquema de backups centralizado con Proxmox Backup Server sobre un NAS casero montado en un Raspberry Pi 4.

No es un laboratorio decorativo. Es una plataforma funcional que puedo romper y reconstruir sin convertirlo en un proyecto eterno.

1. Por qué terminé con un cluster Proxmox VE de 4 nodos

Muchos empiezan con un servidor grande, pero para un entorno doméstico es un error: consumes más, dependes de una sola máquina y cualquier mantenimiento te deja sin nada. Preferí separar funciones y distribuir cargas. Ahí entraron en juego tres HP EliteDesk 800 G5 Mini. Son compactos, totalmente silenciosos y consumen tan poco que puedes dejarlos encendidos todo el día sin pensarlo dos veces.

Los probé individualmente y fue claro que funcionaban bien como nodos ligeros. Corren automatizaciones, servicios auxiliares, contenedores pequeños y backends internos sin complicaciones. Si uno se rompe, no afecta al resto. Esa estabilidad me permitió pensar en ellos como la base del cluster.

Para las cargas intensivas necesitaba otra cosa. Armé un nodo con una board Asus, Ryzen 7 3700X, 32 GB RAM y 1 TB NVMe. Ese nodo existe para una sola razón: potencia. Aquí corren los modelos de IA locales, las transcripciones, las compilaciones pesadas y la VM con GPU passthrough.

Con cuatro nodos listos, unirlos en un cluster Proxmox era obvio. No quería administrar máquinas independientes. El cluster me da una vista única, migraciones cuando las necesito y la libertad de mover servicios según carga o propósito.

No uso Ceph ni HA corporativa. No la necesito. Lo que sí necesito es un cluster flexible, estable y lo suficientemente simple para mantenerlo sin convertirlo en un segundo empleo.

2. Filosofía de diseño: claridad antes que complejidad

Cuando uno monta un homelab es fácil caer en la trampa del “mini datacenter”. El mercado está lleno de servidores usados, switches gigantes y equipos diseñados para un rack profesional, no para una casa. Son ruidosos, consumen demasiado y, en la práctica, terminan apagados la mayor parte del tiempo. Esta vez no quería repetir ese error. El objetivo era construir algo que pudiera usar todos los días sin volver la infraestructura un problema adicional.

Con esa mentalidad llegué a cuatro principios que me guiaron durante el diseño. No son reglas grabadas en piedra, pero sí actitudes que evitan complicarse sin necesidad y ayudan a mantener el sistema entendible incluso meses después de haberlo armado.

El primero fue recordar que el cluster existe por una razón: resolver problemas reales. Tener varios nodos no es un trofeo, es una forma de separar cargas de trabajo y de distribuir esfuerzos. Con tres equipos pequeños puedo mantener servicios estables funcionando todo el día sin estrés, mientras el nodo grande queda reservado para procesos intensivos. Esa separación evita saturaciones innecesarias y mantiene el laboratorio operativo incluso si algo falla.

El segundo principio fue tratar cada carga según su naturaleza. Hay tareas que necesitan procesador, memoria o GPU, y hay tareas que simplemente necesitan estar disponibles. No tiene sentido correr un modelo de IA en un HP EliteDesk, ni dejar un Ryzen de ocho núcleos consumiendo energía solo para alojar un servicio de automatización. Esa distinción hace que el hardware trabaje a favor del proyecto, no en contra.

También aprendí que los errores no deben propagarse. Una mala configuración en una VM no debería afectar al resto del sistema, y mucho menos comprometer los backups. Por eso los datos de Proxmox Backup Server viven en un dispositivo aparte. Es una decisión pequeña, pero reduce enormemente el riesgo de una caída general.

Finalmente, la seguridad no debía depender de buenas intenciones. Prefiero una política simple pero estricta: ningún servicio se expone directamente a Internet. Todo pasa por Cloudflare Tunnel, lo cual elimina la necesidad de abrir puertos y reduce la superficie de ataque a algo mucho más manejable. A nivel práctico, la red permanece cerrada, pero yo sigo teniendo acceso completo desde donde esté.

Al final, la filosofía es bastante sencilla: si algo no agrega valor al día a día, no lo incluyo. Y si algo complica más de lo que resuelve, se descarta. Esa es la diferencia entre un homelab funcional y uno que termina acumulando polvo.

3. La red: el Mikrotik HAP ac3 como columna vertebral

En cualquier homelab la red es la pieza que más fácilmente se descuida. Muchos empiezan dejando todo en la misma subred y funciona… hasta que no funciona. Cuando tienes varios nodos, servicios y pruebas en paralelo, una red plana se vuelve un riesgo y una pérdida de tiempo. Por eso, antes de montar máquinas virtuales, lo primero que ordené fue la infraestructura de red.

El Mikrotik HAP ac3 cumple ese papel sin complicarse. No necesito un switch de 48 puertos, ni VLANs exóticas, ni equipos que consuman lo mismo que un calentador. Lo que sí necesito es control, y RouterOS lo da: reglas claras, tráfico segmentado y visibilidad de lo que pasa.

Terminé definiendo tres VLANs que separan el laboratorio por propósito, no por capricho. La primera es la VLAN de gestión, donde viven las interfaces administrativas de Proxmox, el propio Mikrotik y un par de equipos que uso para mantenimiento. Esta red no se negocia. Si un dispositivo no está autorizado, simplemente no entra. Esa separación evita que un contenedor mal configurado o un equipo invitado llegue donde no debe.

Luego está la VLAN de producción. Aquí corren los servicios estables: automatización, APIs internas, bases de datos ligeras o cualquier aplicación que debe estar siempre disponible. Esta VLAN tiene salida a Internet, pero no puede iniciar conexiones hacia la red de gestión. Tampoco ve la zona de pruebas. Esa barrera mantiene el orden mental y técnico.

Y finalmente está la VLAN de sandbox. Esta red existe para romper cosas sin afectar al resto. Cuando quiero probar una imagen dudosa, ejecutar un scraper experimental o montar un entorno que sé que va a fallar, lo hago aquí. La sandbox no tiene rutas laterales y no puede alcanzar ni a producción ni a gestión. Si algo explota, explota dentro de esa caja.

Con estas tres redes separadas, el laboratorio se vuelve más predecible. Los problemas no se mezclan, los servicios críticos siguen funcionando y puedo experimentar sin afectar la infraestructura principal. No es un diseño complejo, pero sí uno que evita dolores de cabeza.

4. NAS auxiliar: un Raspberry Pi 4 que hace exactamente lo necesario

Para muchos, hablar de un NAS implica pensar en equipos grandes, llenos de bahías y con más funciones de las que uno realmente usa. En mi caso, no necesitaba nada de eso. Lo que buscaba era un lugar confiable donde guardar los backups del laboratorio, sin sumar ruido, calor ni otro servidor x86 que mantener. Y ahí es donde un Raspberry Pi 4 tiene más sentido del que parece.

El Pi, con apenas 1 GB de RAM y un disco externo de 1 TB, cumple un rol muy específico: ser el repositorio del Proxmox Backup Server. No aloja servicios, no ejecuta contenedores y no participa del cluster. Justamente por eso funciona bien. Su valor está en la separación física: si un nodo del cluster falla o si cometo un error en Proxmox, los backups no están en el mismo chasis ni dependen de la misma fuente de poder.

Además consume casi nada. Puede estar encendido meses sin reclamar atención y sin convertirse en un gasto. No compite con los nodos principales ni introduce ruido en la red. Solo hace su trabajo: guardar datos y entregarlos cuando toca restaurar algo. Y en un homelab, muchas veces eso es exactamente lo que se necesita.

5. Cloudflare Tunnel: el fin del port forwarding

Durante mucho tiempo, exponer un servicio desde casa significaba abrir puertos en el router, configurar DynDNS y confiar en que nada extraño apareciera en los logs. Era lo normal, aunque nunca fue una buena idea. Con el tiempo se volvió evidente que ese modelo ya no tiene sentido: aumenta la superficie de ataque, depende de una IP pública estable y obliga a mantener reglas de firewall demasiado frágiles.

En este laboratorio decidí cortar ese modelo de raíz. Ningún servicio se publica mediante port forwarding. Todo pasa por Cloudflare Tunnel, lo que cambia por completo cómo se piensa el acceso remoto. El túnel no requiere abrir nada hacia adentro; es el propio servicio el que establece la conexión hacia Cloudflare. Desde fuera nadie ve la red, nadie conoce mis IP internas y nadie llega a los puertos del Mikrotik.

Además, la autenticación ocurre antes de que la solicitud toque mi infraestructura. Eso elimina la necesidad de exponer paneles de administración, APIs o máquinas virtuales. Cloudflare se encarga de validar identidad y permisos, y solo entonces el tráfico se enruta al servicio correspondiente dentro del homelab.

El resultado es simple: menos superficies expuestas, menos reglas que mantener y un acceso remoto mucho más estable. No complica la operación; la hace más predecible.

6. Distribución lógica de cargas

El hardware por sí solo no resuelve nada. La diferencia está en cómo se usa. Este cluster funciona porque cada nodo tiene un papel claro y no compiten entre sí. Esa separación evita desperdicio de recursos y mantiene el laboratorio estable, incluso cuando estoy probando cosas que sé que pueden fallar.

El nodo con Ryzen 7 es el que marca la pauta cuando se trata de potencia. No lo mantengo encendido permanentemente; se activa cuando necesito entrenar un modelo local, compilar imágenes grandes, procesar audio o video, o ejecutar algo que realmente justifique sus núcleos y su NVMe. Es un equipo pensado para cargas puntuales, no para sostener servicios que pueden correr en otros nodos sin esfuerzo.

Los tres EliteDesk, en cambio, son los que mantienen la operación diaria. En ellos vive la automatización, el monitoreo, los servicios internos y los entornos de pruebas que puedo crear y destruir sin pensarlo mucho. También alojan bases de datos ligeras y contenedores que requieren estabilidad más que potencia. Lo hacen bien, sin ruido y sin obligarme a encender el nodo grande cuando no es necesario.

Esa distribución —potencia en un nodo y constancia en los otros— hace que el cluster sea más eficiente. Cada máquina hace lo que mejor sabe hacer y el conjunto se mantiene ordenado.

7. GPU Passthrough: una estación de trabajo encapsulada

Una de las cosas que quería lograr desde el inicio era aprovechar la GPU del nodo Ryzen dentro de una máquina virtual. No tanto por experimentar, sino porque algunas cargas —modelos de IA, ciertos procesos de transcodificación o tareas de análisis— realmente lo requieren. Configurar GPU passthrough no es difícil, pero tampoco es algo que funcione con un clic.

El proceso implica activar IOMMU, revisar cómo agrupa el hardware el propio kernel y asegurarse de que Proxmox no intente usar la tarjeta para su interfaz. Hay que aislarla, declararla como dispositivo reservado y pasársela directamente a la VM. Es un trabajo puntual, pero vale la pena hacerlo bien porque si te equivocas en un parámetro, la máquina arranca sin vídeo o la GPU queda bloqueada.

Cuando la configuración está limpia, la experiencia cambia. Dentro de la VM —en mi caso Windows— el sistema reconoce la tarjeta como si estuviera instalada físicamente. Instalas el driver oficial de NVIDIA y listo: tienes una estación de trabajo encapsulada que puede ejecutar cargas pesadas sin comprometer al host. Es útil, es estable y me permite trabajar con herramientas que simplemente no funcionarían de manera eficiente en un contenedor.

8. Automatización: n8n como supervisor del laboratorio

Después de un tiempo trabajando con un homelab, uno se da cuenta de que lo más costoso no es la infraestructura, sino el tiempo que se pierde haciendo tareas repetitivas. Por eso para mí la automatización no es un “extra”, es parte del diseño. Si algo puede ejecutarse solo, debe ejecutarse solo. Y en este laboratorio, n8n es quien se encarga de ese trabajo.

Lo uso como orquestador central. Allí programo scrapers que corren en horarios específicos, monitoreo el estado de los nodos y recibo alertas cuando algún contenedor se detiene o un servicio deja de responder. También sirve como capa intermedia entre APIs que no hablan el mismo idioma; n8n traduce, combina y dispara acciones según sea necesario. Es la pieza que conecta servicios que, de otro modo, tendría que gestionar manualmente.

Está alojado en uno de los EliteDesk porque su carga es constante, pero liviana. No necesita núcleos rápidos ni GPU; necesita estabilidad. Y al estar en una VLAN separada, puedo permitir que interactúe con muchas partes del sistema sin exponerlo a entornos de prueba o servicios que todavía no son confiables.

n8n no es el componente más visible del homelab, pero sí es uno de los más importantes. Es el que evita que todo dependa de que yo esté pendiente. Y cuando tienes varios nodos, servicios en diferentes VLANs y pruebas que se ejecutan a cualquier hora, esa diferencia se nota.

9. Proxmox Backup Server: la parte que realmente marca la diferencia

Tener un homelab estable no depende del hardware ni del hipervisor. Depende de qué tan rápido puedes recuperarte cuando algo sale mal. Eso lo aprendí después de romper VMs sin intención, borrar configuraciones en el momento menos oportuno y probar herramientas que, en teoría, eran “seguras”. Por eso, de todas las piezas del laboratorio, Proxmox Backup Server (PBS) es probablemente la que más valor aporta a largo plazo.

PBS no es un sistema de copias “tradicional”. No trabaja a nivel de archivo ni genera imágenes enormes de varios gigabytes cada vez que haces un backup. Lo hace a nivel de bloque y con deduplicación real. Esa diferencia técnica hace que los respaldos no solo ocupen menos espacio, sino que también sean consistentes y predecibles. Si tengo diez máquinas Linux basadas en la misma plantilla, PBS guarda los bloques comunes una sola vez. El resto es incremental. Eso reduce el tiempo de copia y elimina la ansiedad de ver cómo un backup crece sin control.

Pero lo que realmente vuelve útil a PBS no es cómo almacena los datos, sino cómo permite recuperarlos. Puedo restaurar una máquina completa si metí la pata en una actualización, pero también puedo montar el backup como si fuera un sistema de archivos externo y extraer un único archivo de configuración. No necesito revertir toda una VM solo porque borré un archivo en /etc. Esa granularidad convierte un error serio en un problema manejable.

Otra función que uso con frecuencia es el Live Restore. Cuando algo falla en el nodo principal y necesito volver a levantar una máquina inmediatamente, PBS permite iniciar la VM directamente desde el backup mientras copia los bloques necesarios al almacenamiento rápido. La máquina arranca, yo sigo trabajando y la restauración continúa en segundo plano. Es una forma simple de mejorar la continuidad sin convertir el homelab en un proyecto de alta disponibilidad.

En cuanto al almacenamiento, decidí no usar discos internos del cluster. Los backups viven en un Raspberry Pi 4 con 1 GB de RAM y un disco externo. No porque sea más potente, sino porque está fuera del entorno donde ocurren los errores. Si la fuente del nodo Ryzen se daña o si una mala configuración corrompe un datastore, PBS sigue intacto. Esa separación física es tan importante como la lógica.

También programé verificaciones periódicas de integridad. Es un punto que muchos pasan por alto, pero tener un backup que no sabes si se puede restaurar equivale a no tener nada. PBS permite detectar bloques corruptos y evitar sorpresas cuando realmente necesitas recuperar algo.

Las políticas de retención son simples. Realizo copias incrementales diarias de las máquinas críticas y retengo un histórico razonable. Las máquinas de pruebas tienen un esquema más agresivo; la mayoría no vale la pena conservarla por semanas. Con PBS, ajustar la retención es trivial y no afecta la estabilidad del sistema.

En resumen, PBS es la pieza que convierte el laboratorio en un entorno confiable. Me permite experimentar sin miedo, actualizar sin ansiedad y destruir entornos de prueba sin pensar en consecuencias. La infraestructura puede fallar, yo puedo equivocarme, pero mientras PBS funcione, siempre hay un punto seguro al cual volver.

10. Conclusión: una infraestructura pequeña que cumple su función

Construir este homelab no fue un ejercicio de acumular hardware ni de replicar un datacenter en miniatura. Fue, sobre todo, un proceso de entender qué necesito realmente para trabajar, experimentar y validar ideas sin depender de servicios externos. El resultado no es espectacular en apariencia, pero sí en utilidad: un entorno estable, silencioso y con suficiente capacidad para resolver problemas reales.

El cluster de cuatro nodos me da flexibilidad sin sobreingeniería. Los EliteDesk sostienen el día a día y el nodo Ryzen ofrece la potencia cuando hace falta. La red segmentada evita mezclar cosas que no deben mezclarse. Cloudflare Tunnel elimina la exposición innecesaria. Y PBS, apoyado en un NAS simple pero aislado, garantiza que cualquier error —propio o del sistema— se pueda revertir con rapidez.

No hay nada extraordinario en la arquitectura. Lo que la hace funcionar es el equilibrio: cada componente está ahí por una razón y nada sobra. Eso permite que el homelab evolucione cuando debe hacerlo, sin convertirse en un proyecto eterno ni en una carga de mantenimiento.

En resumen, es una plataforma que me permite trabajar con libertad y sin riesgo. Y aunque es pequeña, está hecha con intención. Para un homelab, eso suele ser más importante que cualquier despliegue espectacular.