Un rack de homelab tiene una habilidad peligrosa: parece más serio cuanto más lleno está. Más servidores, más switches, más cables, más etiquetas, más lucecitas. Desde fuera queda precioso. Desde dentro, si no tienes cuidado, se convierte en una colección de decisiones antiguas que siguen consumiendo electricidad porque nadie se atreve a apagarlas.
A mí me gusta el hardware. Ese es parte del problema. Me gusta probar mini PCs, montar clusters, separar servicios, cambiar el firewall, meter almacenamiento nuevo y ver si una arquitectura aguanta mejor que la anterior. El homelab tiene mucho de laboratorio, pero también tiene algo de trastero técnico. Si no haces limpieza de vez en cuando, acabas manteniendo cosas que ya no usarías si empezases hoy.
Este repaso no va de enseñar un rack perfecto. Va de algo más útil: qué corre de verdad, qué aporta, qué sobra y qué cambiaría si tuviese que montarlo otra vez desde cero.
La pregunta incómoda: qué pasaría si apago esto#
Cuando reviso el rack, no empiezo por el inventario. Empiezo con una pregunta más cruel: si apago esta máquina ahora mismo, ¿quién se entera?
Esa pregunta separa el homelab real del escaparate. Hay servicios que si caen molestan al instante: DNS, acceso remoto, backups, domótica, fotos, documentos, autenticación, monitorización mínima. Hay otros que me molestan solo a mí si justo estoy trasteando. Y luego están los que llevan meses encendidos porque un día fueron buena idea.
Un servidor que nadie nota cuando se apaga no es necesariamente inútil, pero tiene que justificar su sitio. Puede ser laboratorio, puede ser cold standby, puede ser nodo de pruebas. Lo que no debería ser es producción imaginaria.
Mi clasificación actual es bastante simple:
- Núcleo doméstico: lo que casa usa o lo que protege datos importantes.
- Producción personal: servicios que uso con frecuencia y quiero estables.
- Laboratorio: cosas que puedo romper sin pedir perdón.
- Archivo o capacidad puntual: almacenamiento, GPU, transcodificación, tareas pesadas.
- Chatarra sentimental: hardware que me gusta, pero que ya no tiene una función clara.
La última categoría duele porque todos tenemos algo ahí. Ese mini PC que fue una ganga. Ese NAS antiguo que todavía funciona. Esa placa que podría servir para algo. Ese “algo” suele llegar tarde o no llegar nunca.
Lo que sí corre de verdad#
En mi rack hay varios bloques que tienen sentido.
El primero es virtualización. Proxmox sigue siendo el centro cuando quiero aislar servicios, mover VMs, probar arquitecturas y tener cierto orden. Para un homelab serio, me sigue pareciendo una base muy cómoda. No porque sea perfecto, sino porque la relación entre flexibilidad y control es buenísima. Puedo tener VMs completas para cosas delicadas, contenedores LXC para servicios ligeros y snapshots o backups con una integración bastante decente.
El segundo bloque es almacenamiento. Aquí soy menos romántico. El almacenamiento no perdona. Puedes tener el dashboard más bonito del mundo, pero si las copias no existen o no restauran, todo lo demás es teatro. En casa quiero una pieza clara para datos familiares, otra para backups y otra para pruebas. Mezclarlas funciona hasta que deja de funcionar.
El tercer bloque es red y acceso. DNS interno, VPN o mesh VPN, reverse proxy cuando toca, certificados y un firewall que no haga la vida imposible. Esto no luce tanto como montar otro cluster, pero es lo que hace que el resto sea usable. Si el DNS local falla, parece que se ha roto medio homelab aunque los servidores estén perfectos.
El cuarto bloque es automatización y observabilidad. No necesito una plataforma de monitorización enorme para todo, pero sí necesito saber si los backups fallan, si un disco se está llenando, si un servicio crítico no responde o si un nodo lleva días raro. La observabilidad en casa tiene que avisar poco y bien.
El quinto bloque son servicios personales: Git, documentos, fotos, media, recetas, dashboards, automatizaciones, alguna base de datos y herramientas que uso de verdad. Aquí soy cada vez más exigente. Si un servicio no mejora mi vida o mi trabajo, tiene que ser muy barato de mantener para quedarse.
Lo que suele sobrar#
Lo que más sobra en un homelab no son servidores. Es ambición mal colocada.
Sobra alta disponibilidad donde no hay impacto real. Montar HA para un servicio que puedo levantar manualmente en diez minutos no siempre compensa. La alta disponibilidad trae complejidad, red, almacenamiento compartido, quorum, reglas, pruebas y mantenimiento. Si todo eso protege algo que apenas uso, he comprado tranquilidad falsa con horas reales.
Sobra Kubernetes cuando Docker Compose habría sido suficiente. Kubernetes me gusta, pero no lo metería por defecto en una casa. Si estoy aprendiendo, perfecto. Si necesito orquestación real, también. Pero para diez servicios personales en un solo nodo, muchas veces es ceremonia. Bonita, potente y completamente innecesaria.
Sobra monitorización que nadie mira. Grafana lleno de paneles puede ser muy satisfactorio, pero si no cambia decisiones, es decoración. Me interesa más una alerta buena sobre backups que veinte gráficas de CPU que jamás consulto.
Sobra hardware duplicado sin rol. Tener varios mini PCs puede ser útil si hay cluster, separación de cargas o laboratorio. Tenerlos encendidos “por si acaso” es otra cosa. Ese “por si acaso” cuesta electricidad, ocupa puertos, genera calor y añade superficie de fallo.
También sobra la idea de que todo debe ser self-hosted. Hay servicios que merecen correr en casa. Hay otros que no. El criterio no debería ser ideológico, sino práctico. Si alojar algo yo mismo me da privacidad, control, aprendizaje o ahorro real, adelante. Si solo me da trabajo, que lo haga otro.
La arquitectura que más sentido me hace hoy#
Si empezase hoy, no montaría el rack por piezas sueltas. Lo diseñaría por capas.
La primera capa sería red estable. Buen router o firewall, switch gestionable, WiFi decente, VLANs mínimas, DNS interno claro y acceso remoto pensado desde el principio. No hace falta una red de empresa. Hace falta una red que no se caiga porque he movido un servicio de sitio.
La segunda capa sería almacenamiento fiable. Un NAS o servidor de almacenamiento con discos vigilados, snapshots donde encajen y backups hacia otro destino. Antes de montar veinte aplicaciones, resolvería dónde viven los datos y cómo vuelven si algo muere.
La tercera capa sería virtualización simple. Uno o dos nodos potentes antes que cinco flojos, salvo que el objetivo sea aprender cluster. Un nodo principal con margen de CPU y RAM suele dar más paz que repartir todo entre máquinas pequeñas y depender de que la red y el almacenamiento compartido estén finos.
La cuarta capa sería servicios esenciales. DNS, backups, gestor de contraseñas si se va a self-hostear, documentos, fotos, acceso remoto, monitorización mínima. Pocas cosas, bien montadas.
La quinta capa sería laboratorio. Separado de lo anterior. Con libertad para romper. Con su propio rango de red, sus snapshots, sus VMs temporales y cero acceso por defecto a los datos importantes.
Esta estructura suena menos emocionante que comprar otro nodo, pero evita el problema clásico: tener mucha infraestructura y poca confianza.
Mini PCs, NAS y servidor grande: dónde encaja cada uno#
Los mini PCs son brillantes para homelab. Consumen poco, hacen poco ruido y con CPUs modernas tienen potencia de sobra para una cantidad absurda de servicios. Para Proxmox van muy bien si eliges modelos con RAM ampliable, NVMe decente y red razonable.
Pero no son mágicos. El almacenamiento interno suele ser limitado. La expansión es peor. La refrigeración depende mucho del modelo. Y si empiezas a colgar discos externos, adaptadores, hubs y cables raros, pierdes parte de la gracia.
Un NAS dedicado sigue teniendo sentido para datos. No porque sea más glamuroso, sino porque el almacenamiento agradece aburrimiento. Bahías claras, discos monitorizados, snapshots, backups y una interfaz pensada para eso. Puedes hacerlo todo con un servidor genérico, pero un NAS bien planteado reduce fricción.
El servidor grande tiene otro papel: cargas pesadas, GPUs, transcodificación, IA local, almacenamiento masivo o laboratorio bruto. Yo no lo usaría para cada servicio pequeño si puedo evitarlo. Una máquina grande encendida todo el día solo para correr cuatro contenedores ligeros es como ir a comprar pan con un camión. Se puede, pero algo falla en el planteamiento.
La combinación que más me gusta ahora es esta: mini PC eficiente para servicios siempre encendidos, NAS para datos y copias, servidor grande para tareas que justifican su consumo, y un nodo de laboratorio que pueda apagarse sin remordimiento.
Energía, ruido y calor importan más de lo que parece#
Al principio calculas CPU, RAM y discos. Luego llega la factura de la luz, el verano y el zumbido constante.
Un homelab doméstico vive en una casa, no en un CPD. Si el rack hace ruido, calienta una habitación o consume como un electrodoméstico grande, alguien lo nota. Y si alguien lo nota para mal, el proyecto pierde puntos aunque técnicamente sea precioso.
Por eso me fijo mucho en consumo en reposo. La mayoría de servicios pasan mucho tiempo esperando. Un nodo que consume poco en idle suele ser mejor compañero que una bestia que solo aprovecho dos horas a la semana. La potencia puntual se puede encender cuando hace falta. El consumo 24/7 no descansa.
También miro el coste mental. Cada dispositivo encendido pide actualizaciones, backups, alertas, limpieza, inventario y cierta responsabilidad. Aunque no lo atiendas, está ahí. El rack no solo consume vatios. Consume atención.
Qué cambiaría si empezase hoy#
Compraría menos hardware al principio. Esto me cuesta admitirlo porque probar cacharros mola. Pero comprar menos y mejor suele ganar.
Empezaría con una red clara, un buen nodo eficiente, almacenamiento serio y backups probados. Después añadiría laboratorio. No antes. El orden importa. Si montas primero lo divertido, acabas construyendo lo importante encima de decisiones improvisadas.
Documentaría antes. No una wiki enorme, sino cuatro cosas: qué corre dónde, qué datos importan, cómo restaurar, qué depende de qué y qué puedo apagar sin consecuencias. Esa documentación vale más que muchas automatizaciones.
Separaría antes producción y pruebas. El día que un experimento rompe algo doméstico, aprendes rápido. Mejor aprenderlo leyendo este párrafo que con alguien preguntando por qué no funciona la tele.
Y pondría una regla de retirada. Si una máquina o servicio no se ha usado en tres meses, se apaga primero y se borra después. Apagar es una prueba magnífica. Si nadie protesta y no lo echas de menos, ya tienes la respuesta.
Mi conclusión actual#
Un buen rack de homelab no es el que más cosas corre. Es el que corre lo correcto con el menor drama posible.
Quiero que el núcleo doméstico sea aburrido, que los datos estén protegidos, que el acceso remoto funcione, que las alertas sean pocas y que el laboratorio tenga sitio para hacer el animal sin romper la casa. Todo lo demás tiene que ganarse su enchufe.
La madurez en un homelab no llega cuando compras más hardware. Llega cuando empiezas a apagar cosas y el sistema mejora.