Si solo tuviera dos máquinas para montar un homelab en casa, no intentaría hacer una versión en miniatura de un cluster empresarial. Esa es la trampa. Dos equipos dan para muchísimo, pero no dan para fingir que tienes alta disponibilidad seria, laboratorio ilimitado, almacenamiento perfecto y mantenimiento invisible.
Con dos máquinas hay que elegir. Y elegir bien.
Mi división sería muy clara: una máquina estable para servicios que usa la casa y otra máquina para laboratorio, pruebas y cargas que pueden romperse. No las repartiría al peso. No pondría la mitad de los contenedores en una y la mitad en otra para que el panel parezca equilibrado. Eso queda bonito cinco minutos y luego se vuelve confuso.
En un homelab doméstico, la pregunta no es “cuántos servicios caben”. La pregunta es “qué pasa si esta máquina se apaga”.
Ahí empieza el diseño.
La Máquina A: producción doméstica#
La primera máquina sería la aburrida. La que no se toca a la ligera. La que no recibe experimentos un domingo por la noche porque me apetece probar una beta.
En esa máquina pondría servicios que tienen valor real para casa:
- DNS interno o bloqueador de anuncios
- Home Assistant si la domótica depende de él
- Vaultwarden si lo uso como gestor principal
- Paperless-ngx si guarda documentos familiares
- Immich si almacena fotos o coordina subidas
- monitorización básica
- reverse proxy interno si simplifica acceso
- automatizaciones pequeñas que no quiero perder
No significa que todo tenga que estar en contenedores dentro de una sola VM. Puede ser Proxmox con varias VMs o LXC. Puede ser Debian con Docker Compose. La plataforma importa menos que la disciplina. La Máquina A debe cambiar poco, estar documentada y tener backups claros.
La llamaría producción doméstica, aunque suene exagerado. Lo es. Si la familia usa algo, si guarda datos personales o si su caída molesta a alguien que no eres tú, ya no es laboratorio.
Eso cambia la forma de tocarla. Actualizaciones con calma. Backups antes. Cambios pequeños. Nada de “ya que estoy, cambio también el proxy, el DNS y la base de datos”. Esa frase es el principio de muchas noches idiotas.
La Máquina B: laboratorio y cargas prescindibles#
La segunda máquina sería el espacio para romper cosas.
Ahí pondría:
- Kubernetes si quiero aprender
- VMs temporales
- pruebas de bases de datos
- servicios nuevos antes de pasarlos a producción
- IA local si consume mucho
- compilaciones
- paneles que quiero probar
- stacks que todavía no entiendo del todo
Esta máquina puede reiniciarse, formatearse o quedarse apagada sin que la casa se enfade. Ese es el criterio. Si un servicio en la Máquina B empieza a ser útil en serio, lo promociono a la Máquina A o lo convierto en algo respaldado y mantenible.
Me gusta pensar en la Máquina B como un taller. Un taller puede estar desordenado. Puede tener piezas a medias. Puede oler a proyecto que se fue de las manos. Lo que no puede pasar es que el taller sea también el cuadro eléctrico de la casa.
Separar así quita mucha ansiedad. Puedo aprender y romper sin mirar de reojo a los servicios familiares. También me obliga a reconocer cuándo una prueba deja de ser prueba.
No repartir por recursos, repartir por riesgo#
El error más habitual con dos máquinas es mirar CPU, RAM y disco como si fueran lo único importante.
“Esta tiene 30% de CPU y la otra 5%, voy a mover cosas.”
A veces tiene sentido. Pero en casa prefiero repartir por riesgo:
- ¿este servicio guarda datos irremplazables?
- ¿lo usa alguien además de mí?
- ¿necesita estar disponible todos los días?
- ¿sé restaurarlo?
- ¿depende de otros servicios?
- ¿puedo apagarlo una semana sin consecuencias?
Un servicio ligero puede ser crítico. Un contenedor DNS consume nada, pero si cae puede romper media experiencia. Una base de datos pequeña puede guardar años de documentos. Un Home Assistant con cuatro automatizaciones importantes puede ser más sensible que una VM enorme de pruebas.
Al revés también pasa. Una carga pesada puede ser prescindible. Un modelo local de IA, un servidor de medios temporal o un cluster de pruebas pueden consumir muchísimo y no importar nada si se apagan.
Por eso no equilibraría las máquinas como si fueran cajas de mudanza. Pondría lo estable junto, lo experimental aparte y asumiría que una puede ir más cargada que la otra. Si la Máquina A se queda corta, entonces el problema no es el reparto. Es que necesito simplificar o comprar mejor hardware.
El almacenamiento es donde se complica#
Con dos máquinas, el almacenamiento pide respeto.
Hay varias opciones:
- datos principales en un NAS separado
- discos locales en la Máquina A
- almacenamiento compartido por NFS o SMB
- ZFS local con snapshots
- backups cruzados entre máquinas
Si tuviera que elegir una configuración sencilla, pondría los datos importantes en almacenamiento estable y haría backups fuera de la máquina que ejecuta los servicios. Si hay NAS, perfecto. Si no hay NAS, usaría discos locales en la Máquina A y copias hacia la Máquina B o hacia un disco externo.
Lo que evitaría es montar un invento donde la Máquina A necesita a la Máquina B para arrancar servicios críticos, y la Máquina B necesita a la Máquina A para resolver nombres o montar rutas. Las dependencias circulares en homelab son veneno lento. Funcionan hasta que reinicias todo después de un corte y descubres que cada pieza está esperando a otra.
Para bases de datos, prefiero almacenamiento local y backup bien hecho antes que una carpeta compartida montada con fe. No digo que NFS no sirva. Digo que una base de datos importante merece menos creatividad.
Los snapshots ayudan, pero no son backup. Repetido hasta que canse. Un snapshot dentro del mismo disco no te salva si el disco muere, si borras el dataset equivocado o si una subida eléctrica se lleva la máquina. Es una capa útil, no una religión.
Red simple, pero con límites claros#
Con dos máquinas no montaría una red absurda. Sí pondría límites.
Como mínimo tendría:
- LAN principal
- red de invitados
- red IoT si hay domótica o dispositivos baratos
- acceso remoto privado
No necesito diez VLANs para sentirme seguro. Necesito que lo crítico no quede expuesto por accidente y que los dispositivos dudosos no puedan pasearse por todo.
La Máquina A debería estar en una zona estable. La Máquina B puede tener más libertad para probar cosas, pero no debería tener acceso sin límites a backups, documentos o credenciales. Si el laboratorio se compromete o se rompe, quiero que el daño quede ahí.
También separaría nombres. Los servicios de producción tendrían nombres limpios y estables. Los de laboratorio pueden vivir con nombres temporales. Parece una tontería, pero ayuda a no mezclar. Si algo está en lab, mi cabeza ya sabe que puede desaparecer.
El acceso remoto lo pondría en la parte estable, no en la experimental. Si dependo de la Máquina B para entrar desde fuera y justo la rompo, me lo he buscado con ganas.
Actualizaciones: dos ritmos distintos#
La Máquina A y la Máquina B no deberían actualizarse igual.
La Máquina B puede ir más alegre. Puedo probar versiones nuevas, cambiar stacks, reiniciar sin ceremonia y romper alguna cosa. Para eso está.
La Máquina A necesita otro ritmo:
- leer cambios importantes antes de actualizar servicios sensibles
- hacer backup previo
- actualizar una cosa cada vez cuando sea posible
- probar acceso desde móvil o portátil después
- no tocar varias capas a la vez
Esto suena lento, pero ahorra tiempo. Lo rápido no es actualizar treinta contenedores en bloque. Lo rápido es saber qué se rompió si algo falla.
Yo reservaría una ventana pequeña al mes para producción doméstica. No hace falta una reunión formal con uno mismo, aunque sería bastante cómico. Basta con tener un momento tranquilo, backups recientes y cero prisa.
En laboratorio, en cambio, acepto más caos. Si un stack se rompe, aprendo. Si una beta falla, fuera. Si algo tarda más de lo razonable, lo destruyo y empiezo otra vez. La Máquina B existe para absorber ese impulso.
Backups por categoría, no por máquina#
Otro error: hacer backup de la máquina entera y pensar que ya está.
Yo separaría backups por tipo de dato:
- configuraciones
- bases de datos
- documentos
- fotos
- secretos
- manifiestos o compose files
- inventario
La Máquina A necesita backups restaurables. La Máquina B necesita menos, quizá solo configuraciones de laboratorio o plantillas. No gastaría el mismo esfuerzo copiando una VM temporal que copiando Paperless-ngx.
También haría una prueba pequeña de restauración. No hace falta restaurar todo cada semana. Pero sí comprobar que puedo recuperar una base de datos, levantar un servicio en otra ruta o abrir documentos desde una copia. Un backup que nunca he probado es una promesa educada.
Con dos máquinas, una estrategia útil es que la Máquina B guarde copias cifradas de la Máquina A, siempre que no sea la única copia. Si hay disco externo o nube fría para lo irremplazable, mejor. La copia cruzada ayuda, pero no sustituye una copia fuera del mismo sitio.
Qué promociona un servicio de laboratorio a producción#
Hay servicios que empiezan como prueba y acaban siendo importantes sin que nadie lo declare. Un día montas algo “para ver”. Dos meses después lo usas a diario. Ese momento hay que detectarlo.
Para mí, un servicio pasa a producción cuando cumple una de estas condiciones:
- guarda datos que me dolería perder
- alguien más lo usa
- lo abro desde fuera de casa
- lo uso para trabajar o gestionar cosas reales
- su caída me obliga a arreglarlo rápido
Cuando eso ocurre, no basta con moverlo de carpeta. Hay que darle tratamiento de producción: backups, documentación, actualizaciones menos impulsivas, nombres estables y una ruta de recuperación.
Esto evita un problema típico del homelab: servicios importantes viviendo en la zona de pruebas porque nacieron allí. Es como criar plantas en vasos de yogur y sorprenderte cuando se caen.
Qué dejaría fuera con solo dos máquinas#
Con dos máquinas sería bastante selectivo.
Dejaría fuera, al menos al principio:
- Ceph como almacenamiento serio
- alta disponibilidad fingida
- demasiadas bases de datos separadas
- observabilidad pesada
- SSO obligatorio para todo
- exposición pública de servicios que no necesitan internet
- automatizaciones de actualización agresivas
No porque esas tecnologías sean malas. Algunas son estupendas. Pero con dos máquinas en casa, cada capa nueva tiene que pagar alquiler. Si añade más mantenimiento del valor que aporta, fuera.
La alta disponibilidad es el ejemplo perfecto. Con dos equipos puedes mejorar recuperación, tener backups, incluso preparar servicios para moverse. Pero si vendes eso como HA completa, te estás contando un cuento. En casa prefiero recuperación sencilla a disponibilidad teatral.
Mi diseño final#
Si tuviera que dibujarlo rápido, quedaría así:
Máquina A:
- Proxmox o Debian estable
- servicios familiares
- DNS o fallback controlado
- Home Assistant si aplica
- gestor de contraseñas si lo uso
- documentos, fotos o sus aplicaciones
- monitorización ligera
- backups automatizados
Máquina B:
- laboratorio
- VMs temporales
- Kubernetes o Docker de pruebas
- cargas pesadas
- IA local
- copias cifradas de Máquina A
- entorno de restauración para ensayos
Red:
- router independiente del homelab
- VPN privada estable
- IoT separada si hace falta
- nombres claros para producción y laboratorio
Backups:
- datos críticos fuera de la máquina que los ejecuta
- copia adicional externa para lo irremplazable
- restauración probada de una muestra
No es el diseño más espectacular. Es el que me dejaría dormir.
La idea importante#
Dos máquinas bastan si aceptas sus límites. Una para estabilidad. Otra para curiosidad. Esa separación mental vale más que muchas capas técnicas.
Lo que no haría es convertir ambas en una mezcla de producción, laboratorio, backups, DNS, pruebas, multimedia y servicios familiares. Eso funciona hasta que algo falla y no sabes qué puedes apagar sin romper otra cosa.
Un homelab doméstico bueno no es el que parece más profesional. Es el que puedes mantener cansado, con poco tiempo y sin tener que pedir perdón en casa porque rompiste internet intentando probar una herramienta nueva.
Con dos máquinas, el truco es no creerte más grande de lo que eres. Y eso, para gente que disfruta montando cacharros, cuesta bastante más que instalar cualquier cosa.