Hay una mentira muy cómoda en los homelabs: “es solo un laboratorio”. Suena bien hasta que el laboratorio también lleva el DNS de casa, las fotos familiares, el gestor de contraseñas, Home Assistant, las copias de seguridad y el panel donde miras si algo se ha caído. En ese momento ya no es solo un laboratorio. Es producción doméstica con pegatinas de hobby.
A mí me costó asumirlo. Durante mucho tiempo metí servicios serios y pruebas en el mismo saco porque técnicamente podía hacerlo. Proxmox lo aguanta, Docker lo aguanta, un mini PC moderno lo aguanta casi todo si no te vienes arriba. El problema no es si la máquina puede. El problema es si tú puedes mantenerlo sin convertir cada prueba de domingo en una ruleta rusa para la casa.
La separación entre producción, laboratorio y cacharreo no es postureo enterprise. En casa tiene incluso más sentido, porque no hay equipo de guardia ni ventana de mantenimiento formal. Si rompes algo, el responsable eres tú. Y si lo que rompes afecta a la familia, el SLA lo dicta alguien con menos paciencia que un comité de cambios.
Qué considero producción en casa#
Producción doméstica no significa facturación, Kubernetes con tres entornos ni un tablero lleno de KPIs. Para mí producción es cualquier cosa que, si cae, molesta a otra persona o me crea un problema real.
Ahí entran cosas bastante mundanas:
- DNS de la red local.
- Acceso remoto seguro.
- Gestor de contraseñas.
- Home Assistant si controla luces, calefacción, enchufes o rutinas familiares.
- Copias de seguridad.
- Fotos y documentos.
- Servicios de monitorización básica.
- Algún panel o automatización que uso todos los días.
No todo tiene la misma gravedad. Si se cae el lector RSS, me da igual. Si se cae el DNS y media casa deja de navegar, ya no me da igual. Si se rompe el servidor de fotos pero tengo copias, fastidia. Si se rompe sin copias, eso ya no es homelab, es negligencia con interfaz web.
La primera decisión útil es clasificar servicios por impacto, no por tecnología. Un contenedor pequeño puede ser crítico. Una VM enorme puede ser totalmente prescindible. El tamaño técnico engaña.
Mi regla: lo crítico debe ser aburrido#
Lo que usa la casa tiene que ser aburrido. Esta frase parece poco inspiradora, pero es la base de un homelab sano.
Aburrido significa pocas dependencias raras, actualizaciones controladas, backups claros, documentación mínima y una ruta de vuelta. No significa viejo ni cutre. Significa predecible.
Si un servicio es crítico, no lo meto en el mismo host donde pruebo cosas agresivas. Tampoco lo ato a una versión nightly porque trae una función bonita. No lo pongo detrás de tres proxies distintos si con uno basta. No lo actualizo a las doce de la noche porque me ha dado un ataque de productividad.
El cacharreo necesita justo lo contrario: libertad para romper. Probar un proxy nuevo, cambiar una base de datos, montar un cluster raro, jugar con almacenamiento distribuido, desplegar una herramienta que promete mucho y luego no sirve para nada. Eso es parte del aprendizaje. Pero ese aprendizaje no debería poder dejar sin DNS a la casa.
Cuando mezclas ambos mundos, empiezas a tomar malas decisiones. No pruebas por miedo a romper. O rompes porque se te olvida que ese nodo tenía algo importante. Las dos opciones son malas.
Tres zonas mentales, aunque solo tengas dos máquinas#
No hace falta tener un rack enorme para separar bien. La separación puede ser física, lógica o simplemente disciplinada. Lo importante es que sea explícita.
Yo lo dividiría en tres zonas.
La primera es producción doméstica. Aquí viven los servicios que tienen valor real. DNS, backups, fotos, contraseñas, automatización estable, acceso remoto y monitorización básica. Pocas cosas, bien cuidadas.
La segunda es laboratorio. Aquí pruebo herramientas que podrían acabar en producción, pero todavía no han ganado ese derecho. Un nuevo gestor de contenedores, una alternativa a un servicio actual, una VM para evaluar una distribución, un sistema de backups que quiero entender antes de confiarle nada.
La tercera es cacharreo puro. Aquí vale casi todo. Clusters efímeros, pruebas de IA local, despliegues que probablemente borraré mañana, scripts que no quiero cerca de nada serio, versiones beta, hardware raro, experimentos de red que huelen a tarde perdida.
La gracia está en no fingir que todo es laboratorio. Si llevas seis meses usando un servicio todos los días, ya es producción aunque lo instalaras “para probar”. Promocionarlo mentalmente obliga a cuidarlo mejor.
Separación física: la opción limpia#
La forma más sencilla de separar es usar hardware distinto.
Un mini PC eficiente para producción doméstica. Un NAS o servidor de almacenamiento para datos. Otro nodo, VM o equipo viejo para laboratorio. Si algo de pruebas se rompe, no toca lo importante.
Esto tiene ventajas claras. Los límites son fáciles de entender. Puedes apagar el laboratorio sin miedo. Puedes reinstalarlo sin revisar una lista infinita. Puedes probar cosas de red con menos riesgo si no está en la ruta principal de casa.
El coste es obvio: más hardware, más consumo, más cables y más mantenimiento. Tampoco hace falta exagerar. Un mini PC pequeño para producción y otro para pruebas ya cambia mucho la película. Incluso una Raspberry Pi o un equipo viejo pueden servir para cacharreo si el objetivo no es rendimiento.
Lo que no haría es usar un único servidor grande para todo sin ninguna separación interna. Puede parecer eficiente, pero si ese servidor se convierte en NAS, hypervisor, firewall, laboratorio, media server, DNS y zona de pruebas, cada reinicio se vuelve una negociación contigo mismo.
Separación lógica: cuando tienes un solo host#
Si solo tienes una máquina, todavía puedes separar.
En Proxmox, la separación mínima sería usar VMs o LXCs distintos para producción y laboratorio, con nombres claros, backups separados y etiquetas mentales fuertes. No mezclar servicios críticos con pruebas dentro del mismo contenedor. No usar el mismo stack de Docker para todo. No montar una carpeta compartida gigante donde cualquier experimento pueda tocar datos importantes.
En Docker, separaría al menos por compose files, redes, volúmenes y rutas. Producción en un directorio estable, laboratorio en otro, cacharreo en otro que pueda borrarse entero sin drama. Parece una tontería hasta que un sábado quieres limpiar y no sabes qué volumen corresponde a qué.
También ayuda separar por dominios internos. Por ejemplo, servicios estables bajo servicio.home.arpa o un dominio interno equivalente, pruebas bajo lab.home.arpa, cacharreo bajo algo que te recuerde que no debes confiar en ello. No hace falta montar una tesis de DNS. Basta con que el nombre avise.
La documentación mínima también cuenta como separación. Un archivo con “esto es crítico”, “esto se puede borrar” y “esto depende de esto” evita muchos sustos. No hace falta Notion, una wiki preciosa ni diagramas de consultora. Un markdown honesto vale.
La red es donde más fácil se lía#
Separar servicios es relativamente fácil. Separar red sin pasarse de listo cuesta más.
Las VLANs ayudan, pero solo si sabes por qué las usas. Una VLAN para IoT, otra para servidores, otra para clientes normales y quizá otra para laboratorio puede tener sentido. Lo que no tiene sentido es montar siete VLANs, romper mDNS, pelearte con el casting de la tele y acabar desactivando medio firewall para que funcione una bombilla.
Mi criterio ahora es simple. Producción doméstica debe tener red estable. Laboratorio debe tener límites. Cualquier cosa que toque routing, firewall, DNS principal o DHCP merece plan de vuelta antes de tocarla.
Si quiero probar un DNS nuevo, no lo sustituyo directamente para toda la casa. Lo pruebo en un cliente, luego en una VLAN o grupo pequeño, luego ya veremos. Si quiero probar un firewall nuevo, no lo convierto en puerta de enlace principal sin tener el router anterior listo. Si quiero tocar Tailscale, Cloudflare Tunnel o reverse proxy, miro qué servicios dependen de eso antes.
El error clásico es probar en la ruta crítica porque es más cómodo. También es más cómodo cruzar una autopista con los ojos cerrados si solo miras los primeros dos segundos.
Backups separados, no decorativos#
Separar producción y laboratorio no sirve de mucho si las copias son una sopa igual de confusa.
Los servicios de producción necesitan backups con tres propiedades: sé qué incluyen, sé dónde están y he probado restaurarlos. Si falla cualquiera de las tres, tengo una esperanza, no un backup.
El laboratorio puede tener snapshots o copias rápidas, pero no debería ocupar el mismo nivel mental que los datos importantes. No necesito guardar cada prueba. De hecho, borrar laboratorio a menudo es sano. Si no puedo reconstruirlo, quizá estaba más cerca de producción de lo que admitía.
Yo separaría también la política de retención. Producción con retención más larga y destino externo. Laboratorio con retención corta. Cacherreo con cero apego. El espacio en disco se llena muy rápido cuando todo parece importante durante cinco minutos.
Y ojo con los volúmenes compartidos. Si un servicio de pruebas puede escribir en la misma carpeta donde están datos reales, la separación es cosmética. Los permisos importan. Las rutas importan. Los montajes importan.
Cómo promociono un servicio de laboratorio a producción#
Un servicio no debería pasar a producción solo porque lleva dos semanas funcionando. Tiene que cumplir unas condiciones mínimas.
Primero, tiene que resolver un problema real. Si solo me divierte, se queda en laboratorio.
Segundo, tiene que tener backup. Configuración, datos, secretos y procedimiento básico de restauración. No hace falta escribir una novela, pero sí saber cómo volvería a levantarlo.
Tercero, tiene que tener actualizaciones razonables. Si el proyecto está abandonado o cambia todo cada semana, me lo pienso mucho antes de meterlo en casa.
Cuarto, tiene que ser entendible. Si dentro de tres meses no voy a recordar cómo funciona, necesito documentarlo o simplificarlo.
Quinto, tiene que fallar de forma tolerable. Si una caída bloquea algo importante, necesita redundancia, plan B o al menos una forma rápida de desactivarlo.
Esta lista filtra bastante. Muchos servicios molan el primer día y dejan de tener sentido cuando les pides madurez mínima. Bien. Ese es el filtro haciendo su trabajo.
Qué dejo fuera de producción aunque me guste#
Hay cosas que prefiero mantener lejos de lo crítico.
Herramientas nuevas de automatización que ejecutan acciones sobre otros servicios. Agentes IA con permisos amplios. Sistemas de actualización automática demasiado agresivos. Proxies que reescriben medio tráfico. Servicios que requieren bases de datos delicadas si no tengo claro el backup. Cualquier cosa que necesite privilegios raros porque “es más cómodo”.
No es miedo. Es higiene.
Me encanta probar herramientas nuevas, pero una casa no es un entorno de staging con humanos opcionales. Si una automatización apaga algo que no debe o un experimento rompe acceso remoto cuando estoy fuera, el aprendizaje sale caro.
También dejo fuera de producción muchos dashboards. Los dashboards son peligrosos porque parecen infraestructura. La mayoría son decoración útil. Si se caen, no pasa nada. Que estén bonitos no significa que sean críticos.
Mi diseño ideal para dormir tranquilo#
Si tuviera que dejar una arquitectura doméstica sensata, haría algo así.
Producción mínima en un mini PC estable o NAS capaz. DNS secundario si el DNS principal está self-hosted. Backups locales y al menos una copia fuera. Acceso remoto que no dependa de una sola pieza rara. Servicios críticos con documentación corta. Monitorización que avise de lo importante, no de cada estornudo.
Laboratorio en otro nodo o en VMs claramente marcadas. Sin acceso de escritura a datos familiares. Sin estar en la ruta de internet de la casa. Con snapshots antes de pruebas grandes. Con permiso emocional para destruirlo.
Cacharreo en entornos desechables. Docker compose temporal, VMs que se borran, clusters que nacen y mueren. Si algo ahí empieza a ser útil, se documenta y se promociona. Si no, se borra sin nostalgia.
La clave no es tener más máquinas. Es tener menos confusión.
Señales de que lo tienes demasiado mezclado#
Hay varias señales bastante claras.
Te da miedo apagar un nodo porque no recuerdas qué corre ahí. No sabes qué servicios dependen de tu reverse proxy. Un experimento tiene acceso a carpetas importantes. Actualizar una herramienta de pruebas puede romper algo que usa la casa. Tienes backups, pero no sabes de qué. Todo se llama docker y vive en el mismo directorio. Tu DNS principal está en el mismo sitio donde pruebas contenedores aleatorios. El laboratorio no se puede borrar.
Si te reconoces en tres o cuatro, toca ordenar. No por estética, sino por supervivencia.
Conclusión: el homelab mejora cuando acepta responsabilidades#
Un homelab doméstico puede ser laboratorio, infraestructura y hobby a la vez. Lo que no puede ser es todo mezclado sin consecuencias.
Separar producción, laboratorio y cacharreo me parece una de esas decisiones aburridas que luego salvan tardes enteras. Te deja probar más, no menos. Te quita miedo. Te obliga a cuidar lo que importa y a borrar lo que solo ocupaba sitio.
La madurez en un homelab no es tener Kubernetes, Ceph o alta disponibilidad. Es poder romper algo un sábado por la tarde sin que la casa se entere. Y si eso suena poco épico, perfecto. La infraestructura doméstica buena suele tener esa pinta: discreta, aburrida y preparada para que tú puedas seguir jugando sin quemar el salón.