Si empezara mi homelab desde cero, no compraría primero más hardware. Haría una lista de cosas que no quiero mantener. Suena menos divertido, lo sé. Nadie se mete en este mundo para escribir una lista de renuncias. Uno entra mirando mini PCs, switches, NAS, racks, clusters y dashboards con grafiquitas. Luego pasan los meses y descubres que el coste real no está solo en la factura de la luz. Está en la atención que te roba.
Un homelab sano no es el que tiene más servicios. Es el que puedes explicar sin abrir siete pestañas, el que puedes apagar parcialmente sin que la casa se enfade, el que no necesita una ceremonia cada vez que actualizas un contenedor. Después de montar, romper, migrar y mantener demasiadas cosas, tengo bastante claro qué dejaría fuera si empezara hoy con la cabeza un poco más fría.
No hablo de montar algo aburrido. Hablo de montar algo que siga dando gusto usar dentro de seis meses. Esa diferencia importa.
No empezaría con un cluster grande#
La fantasía del cluster entra pronto. Tres nodos, alta disponibilidad, migraciones en caliente, almacenamiento compartido, todo muy serio. Y sí, mola. También es una forma estupenda de multiplicar problemas cuando todavía no sabes qué cargas vas a tener.
Si empezara de cero, pondría primero un servidor principal bueno y un equipo secundario simple. Nada más. Un nodo que corre lo importante y otro que sirve para backups, pruebas o emergencia. El cluster vendría después, cuando haya una razón real para justificarlo.
La alta disponibilidad doméstica tiene sentido en algunos casos, pero no en todos. Si tienes servicios que usa la familia a diario, como domótica, DNS o contraseñas, quieres reducir cortes. Eso no significa que necesites convertir tu casa en una mini empresa. A veces una copia buena, una restauración ensayada y un equipo de repuesto apagado son más útiles que tres nodos con Ceph, quorum, red dedicada y una tarde mensual de mantenimiento.
Ya conté parte de esto en alta disponibilidad en casa, pero la versión corta es esta: si no sabes qué problema resuelve el cluster, probablemente estás comprando complejidad porque tiene luces bonitas.
No montaría Kubernetes para todo#
Kubernetes es fantástico cuando lo necesitas. También puede ser una trituradora de tiempo en un homelab pequeño. Lo digo con cariño, porque me gusta. Pero si estás empezando y tu objetivo es correr diez servicios en casa, Docker Compose te va a dar menos guerra.
La diferencia no está solo en arrancar contenedores. Está en todo lo que viene alrededor. Ingress, certificados, storage, backups, secrets, actualizaciones, observabilidad, políticas, nodos, red. Cada pieza es razonable por separado. Juntas forman una criatura que exige atención.
Si montara de cero, usaría Compose para servicios domésticos y dejaría Kubernetes para laboratorio, aprendizaje o cargas que de verdad se beneficien de ese modelo. No metería Paperless, Vaultwarden, Mealie o un DNS familiar en un cluster solo para sentir que estoy usando tecnología seria. Lo serio es que funcione cuando alguien lo necesita.
Kubernetes tiene su sitio. El problema es usarlo como respuesta por defecto. En casa, demasiadas veces, la respuesta correcta es un compose.yaml bien escrito, un backup probado y una nota clara de cómo levantarlo otra vez.
No duplicaría servicios por probar alternativas#
Esta es una trampa muy común. Montas una herramienta de monitorización. Luego aparece otra más ligera. Después otra con mejor interfaz. Al final tienes Uptime Kuma, Beszel, Grafana, Prometheus, Netdata y una colección de agentes que vigilan cosas parecidas. Irónico, porque el sistema de monitorización acaba siendo parte del problema que intentaba resolver.
Si empezara hoy, aplicaría una regla dura: una categoría, una herramienta principal. Una para monitorización ligera. Una para dashboards, si hace falta. Una para backups. Una para documentación. Si quiero probar otra, la pruebo en laboratorio y pongo fecha de caducidad.
Probar software es parte de la gracia del homelab. Mantener software duplicado no. Hay servicios que se quedan viviendo porque “ya están montados”. Esa frase es peligrosa. Si algo no tiene dueño, uso o plan, se convierte en polvo digital.
La pregunta útil no es “¿puedo montarlo?”. Casi siempre puedes. La pregunta es “¿quiero ser responsable de esto dentro de tres meses?”. Esa segunda pregunta ahorra muchas tonterías.
No expondría tantos servicios hacia fuera#
Exponer servicios es otro punto donde iría con más calma. Al principio quieres acceder a todo desde cualquier sitio. Paneles, dashboards, apps, documentación, fotos, automatizaciones. Entre túneles, VPN, reverse proxy y DNS, es fácil terminar con media casa visible desde internet o semivisible mediante capas que ya no recuerdas bien.
Mi enfoque actual sería mucho más seco. Lo familiar y sensible, por VPN. Lo público, aislado. Lo administrativo, nunca expuesto sin una razón muy buena. Y si un servicio solo lo uso yo una vez al mes, no necesita un dominio precioso con certificado y login bonito.
Cloudflare Tunnel y Tailscale son herramientas muy cómodas. Precisamente por eso conviene no usarlas como excusa para publicar todo. La comodidad baja la fricción, pero también baja el umbral para hacer cosas tontas.
Para un homelab doméstico, la superficie de ataque debería ser aburrida. Pocas puertas, nombres claros y una forma de entrar que puedas auditar sin leer un mapa arqueológico. Ya habrá tiempo de complicarlo cuando haya una necesidad real.
No convertiría cada idea en servicio permanente#
Hay ideas que merecen una tarde. No merecen un contenedor eterno.
Un lector RSS nuevo, un gestor de bookmarks, una wiki, una app de recetas, un sistema de notas, un panel para ver métricas del tiempo, un bot para avisos, una herramienta para organizar PDFs. Todas pueden ser útiles. Ninguna debería quedarse encendida por inercia.
Si empezara de cero, separaría tres estados:
- Producción doméstica, lo que la casa usa o lo que contiene datos importantes.
- Laboratorio, lo que estoy probando activamente.
- Cementerio, lo que se apaga o se borra.
El cementerio es sano. Borrar servicios no es fracasar. Es mantener el homelab respirable. De hecho, una de las mejores mejoras que puedes hacer en casa es apagar cosas. Menos actualizaciones, menos backups, menos puertos, menos dudas.
Lo que no haría es dejar veinte servicios en una especie de limbo técnico. Ni importantes, ni muertos. Esos son los que más molestan, porque aparecen en cada mantenimiento y nunca sabes si romperás algo al tocarlos.
No compraría hardware “por si acaso”#
El hardware barato es una droga suave. Un mini PC de oferta, un switch gestionable, más RAM, otro SSD, una tarjeta de red, un SBC curioso. Cada compra parece razonable. El problema es el conjunto.
Si empezara hoy, compraría menos y mejor. Un servidor principal con margen de RAM, almacenamiento decente y red suficiente. Un NAS o servidor de backups si los datos lo justifican. Un switch que no se me quede corto, pero sin montar una topología de datacenter en una casa.
El “por si acaso” llena cajones. También llena la cabeza. Cada aparato necesita firmware, cables, enchufe, etiqueta, documentación y una decisión cuando algo falla. Incluso apagado ocupa espacio mental.
No digo que haya que ser monje. Esto va de cacharrear. Pero hay una diferencia entre tener piezas para aprender y acumular hardware porque comprarlo es más fácil que ordenar lo que ya tienes.
En mi caso, si empezara hoy, pondría un presupuesto anual de homelab. No por austeridad dramática, sino para obligarme a elegir. Si entra un equipo, debería salir otro o justificar bien su sitio.
No usaría dashboards como sustituto de documentación#
Los dashboards dan una sensación peligrosa de control. Ves CPU, RAM, discos, uptime y piensas que tienes el sistema entendido. Luego se rompe algo y descubres que no sabes dónde vive la base de datos, qué volumen contiene los datos buenos, qué backup sirve o qué dependencia arranca primero.
Si empezara de cero, documentaría antes de decorar. Una página simple por servicio:
- Qué hace.
- Dónde corre.
- Qué datos guarda.
- Cómo se actualiza.
- Cómo se restaura.
- De qué depende.
- Qué puedo apagar sin miedo.
Eso vale más que muchas gráficas. No queda tan bonito, pero salva tardes. Sobre todo cuando estás cansado o cuando llevas meses sin tocar ese servicio.
Los dashboards tienen sitio. Me gustan. Pero no deberían ser la fuente de verdad. La fuente de verdad debería ser una documentación pequeña, mantenible y escrita para tu yo del futuro, que probablemente tendrá menos paciencia que tú.
No automatizaría lo que aún no entiendo#
Automatizar pronto da gustito. Scripts, cron, Ansible, workflows, actualizaciones automáticas, notificaciones. El problema es automatizar un proceso que todavía no dominas. Entonces no estás ahorrando trabajo. Estás escondiendo incertidumbre detrás de una tarea programada.
Si empezara de cero, haría primero el proceso manual dos o tres veces. Backup, actualización, despliegue, restauración, migración. Cuando entienda los pasos y los fallos posibles, automatizaría lo aburrido.
La automatización buena reduce carga. La mala genera ruido. Te manda avisos que ignoras, toca servicios que no debería, falla en horarios raros y te obliga a depurar el automatismo además del problema original.
Mi regla actual: si una automatización falla, debe dejar claro qué hizo, qué no hizo y cómo continuar a mano. Si no puede hacer eso, quizá no está lista para vivir en producción doméstica.
No metería datos familiares en servicios inmaduros#
Esta me parece la regla más importante. Fotos familiares, documentos, contraseñas, domótica crítica y copias importantes no son juguetes. Puedes usar software self-hosted para todo eso, pero con respeto.
No metería fotos familiares en una app recién desplegada sin entender backups, rutas, base de datos y proceso de actualización. No pondría contraseñas en un servicio sin 2FA, copia externa y prueba de restauración. No haría depender calefacción, luces o rutinas familiares de una automatización que acabo de copiar de internet.
El self-hosting en casa es una mezcla rara. Puedes aprender mucho y a la vez tocar cosas que afectan a gente que no ha pedido participar en tu laboratorio. Conviene recordar eso. Si algo lo usa la familia, deja de ser solo cacharreo.
La regla práctica: primero laboratorio, luego datos falsos, luego backup, luego datos reales. Saltarse pasos puede salir bien, pero cuando sale mal no es una anécdota técnica. Es un problema doméstico.
No montaría una red demasiado lista para una casa normal#
VLANs, firewall, DNS interno, reglas, redes de laboratorio, IoT separado, invitados, servidores, cámaras. Todo tiene sentido. También puede convertirse en una estructura tan fina que nadie más puede vivir con ella.
Si empezara de cero, montaría una red con pocas zonas y nombres claros. Casa, IoT, laboratorio, invitados. Poco más. No haría una VLAN por cada ocurrencia. No pondría reglas tan específicas que seis meses después parezcan escritas por otro humano.
La red de casa tiene que proteger, pero también tiene que dejar vivir. Si cada impresora, móvil o bombilla exige una investigación forense, te has pasado de listo. Lo digo porque es muy fácil pasarse.
Me gusta separar laboratorio y servicios críticos. Me gusta tener DNS interno decente. Me gusta poder acceder desde fuera sin abrir puertos a lo loco. Pero todo eso debería sentirse como infraestructura, no como una oposición pública.
Mi lista corta si empezara mañana#
Si mañana tuviera que montar un homelab desde cero, empezaría con esto:
- Un servidor principal con Proxmox o Unraid según el caso.
- Un destino de backup separado.
- Docker Compose para la mayoría de servicios.
- Tailscale o WireGuard para acceso remoto privado.
- DNS interno simple.
- Documentación mínima desde el primer día.
- Monitorización ligera.
- Un laboratorio separado para romper cosas sin miedo.
Y dejaría fuera, al menos al principio:
- Cluster grande.
- Kubernetes para servicios domésticos básicos.
- Alta disponibilidad teatral.
- Tres herramientas para el mismo trabajo.
- Servicios expuestos por comodidad.
- Hardware comprado sin carga real.
- Automatizaciones antes de entender el proceso.
No es una lista contra el cacharreo. Es una lista a favor de seguir disfrutándolo. La diferencia entre un homelab y un segundo trabajo suele estar en cuántas cosas aceptas mantener sin necesitarlas.
La poda también es parte del homelab#
Hay una satisfacción rara en apagar servicios. No es tan vistosa como estrenar un mini PC, pero se nota. Menos ruido. Menos actualizaciones. Menos dudas cuando algo falla. Menos miedo a tocar.
Si empezara de cero, intentaría diseñar el homelab como algo que pueda podarse. Servicios con dueño claro, datos localizados, backups comprensibles y documentación suficiente. Si una pieza deja de aportar, fuera. Sin drama.
El objetivo no es tener el homelab más impresionante. Es tener uno que encaje con tu casa, tu tiempo y tus ganas reales de mantenerlo. A veces eso significa montar menos. Y, curiosamente, suele funcionar mejor.