Durante bastante tiempo pensé en el homelab como si el problema principal fuese tener más capacidad. Más nodos, más discos, más interfaces de red, más margen para probar cosas. Es una fase divertida y creo que casi todos pasamos por ahí. Ves un mini PC con dos puertos 2.5 GbE, un NAS de segunda mano o un servidor empresarial a precio ridículo y la cabeza empieza a justificarlo antes de mirar el enchufe.
Luego llega la factura eléctrica, el calor de verano, el ruido, las actualizaciones pendientes y esa sensación de que tienes media casa trabajando para servir cuatro cosas que igual podrían vivir juntas sin drama.
Ahí cambia la pregunta. Ya no es “cuánto puedo montar”. Es “qué merece estar encendido todo el día”.
Para mí, un homelab de bajo consumo en 2026 no es un homelab pequeño por obligación. Es uno más deliberado. No consiste en comprar el mini PC más eficiente de la semana y meterlo todo ahí con fe. Consiste en separar cargas, consolidar lo aburrido, apagar laboratorio cuando no se usa y no ahorrar justo en la parte donde perder datos o disponibilidad te saldría carísimo en tiempo.
mi punto de partida#
En casa he acabado separando mentalmente el homelab en tres mundos.
El primero es producción doméstica. DNS, contraseñas, fotos, documentos, Home Assistant si controla cosas reales, monitorización mínima, copias y algún servicio web que quiero tener siempre arriba. Esto no tiene por qué ser enorme, pero sí tiene que ser aburrido. Aburrido en el buen sentido.
El segundo es almacenamiento. Discos, snapshots, copias, medios, datos familiares y cualquier cosa que no quiero reconstruir a mano. Aquí el bajo consumo importa, pero no tanto como la fiabilidad. Apagar discos a lo loco para ahorrar unos euros puede terminar en más desgaste, más latencia y más mala leche.
El tercero es laboratorio. Kubernetes, pruebas de bases de datos, modelos locales, VMs temporales, servicios que estoy evaluando, cacharreo de red. Este mundo no necesita estar encendido 24/7. Que a veces lo tengamos así dice más de nuestra pereza operativa que de una necesidad real.
La primera mejora de consumo suele salir de aquí. No de cambiar hardware, sino de dejar de tratar el laboratorio como producción.
lo que apagaría sin remordimientos#
Apagaría cualquier nodo que solo exista para “tener cluster” si no está prestando un servicio real. Suena duro, pero en casa la alta disponibilidad se nos va de las manos muy rápido. Tres nodos encendidos para que un dashboard de pruebas sobreviva a la caída de un mini PC no es alta disponibilidad. Es decoración cara.
También apagaría GPUs que solo se usan de vez en cuando. Si tienes una gráfica para transcodificación, IA local o trabajos puntuales, perfecto. Pero si la mayor parte del día está esperando, conviene preguntarse si puede vivir en un servidor que se encienda bajo demanda. Hay casos donde no compensa complicarse. Si Plex transcodifica todos los días para la familia, déjalo tranquilo. Si la GPU se usa dos tardes al mes para probar modelos, no necesita calentar la habitación como si fuese infraestructura nacional.
Apagaría nodos de laboratorio Kubernetes cuando no hay laboratorio. K3s, Talos, MicroK8s o lo que toque. Me encanta tener un cluster para aprender, pero no todo aprendizaje tiene que facturarse en kWh. Si los servicios importantes ya viven en Docker, LXC o VMs estables, el cluster de pruebas puede descansar.
Y apagaría cualquier “servidor viejo de reserva” que lleva meses encendido por si acaso. El “por si acaso” es el impuesto invisible del homelab. Una cosa es tener hardware de repuesto preparado. Otra distinta es tenerlo gastando energía, acumulando polvo y pidiendo actualizaciones porque algún día podría hacer falta.
lo que consolidaría#
Consolidaría servicios pequeños y estables. Uptime Kuma, AdGuard Home, pequeños bots, dashboards, lectores RSS, Linkding, Mealie, alguna web estática, automatizaciones ligeras. No necesitan su propia VM cada uno salvo que haya una razón concreta.
Para este tipo de servicios, un mini PC moderno con NVMe, 32 GB de RAM y un procesador eficiente puede hacer muchísimo. Mucho más de lo que parece si no lo llenamos de capas innecesarias. Docker Compose sigue siendo una herramienta magnífica para casa porque tiene poca ceremonia, se entiende meses después y no requiere mantener un cluster entero para levantar tres contenedores.
También consolidaría paneles y herramientas auxiliares. Es fácil acabar con Portainer, Dockge, Grafana, Uptime Kuma, Beszel, Prometheus, Netdata y tres sistemas de alerta mirando lo mismo con distinta cara. Para un homelab pequeño, eso no es observabilidad. Es ruido con iconos.
Mi regla ahora es simple: si una herramienta no cambia una decisión operativa, probablemente sobra. Si me avisa de algo que no voy a arreglar, sobra. Si requiere más mantenimiento que el servicio que vigila, sobra muchísimo.
Consolidaría servicios internos detrás de un reverse proxy sencillo. No todo necesita salir a Internet. De hecho, casi nada debería salir a Internet por defecto. Un proxy interno con nombres decentes, TLS si procede y acceso por VPN o Tailscale suele cubrir el 90 por ciento de la vida doméstica sin abrir medio router.
dónde no recortaría#
No recortaría en backups. Me da igual que el servidor principal consuma 8 W menos si luego las copias viven en el mismo disco, en el mismo equipo o en una configuración que nadie ha restaurado. Ahorrar energía perdiendo separación de copias es una mala jugada.
Tampoco recortaría en almacenamiento principal si guarda fotos, documentos o datos familiares. Aquí soy bastante conservador. Prefiero menos servicios y mejores discos. Prefiero tener una copia externa aburrida antes que otro nodo bonito. Prefiero una restauración probada antes que un dashboard verde.
No recortaría en red básica. Router, switch principal, DNS de respaldo y acceso remoto administrativo tienen que ser simples. Puedes tener VLANs, firewall decente, VPN y DNS interno sin convertir cada reinicio en una partida de ajedrez. El día que algo falla, agradecerás que la red mínima no dependa de cinco piezas autoalojadas que viven justo en el nodo que acabas de apagar.
Y no recortaría en documentación operativa. Esto no consume vatios, pero ahorra horas. Un inventario pequeño con servicios, ubicaciones, puertos, dependencias y orden de restauración vale más que muchos cacharros. Especialmente cuando estás cansado y no recuerdas dónde demonios metiste la base de datos de ese servicio que “era temporal”.
el falso ahorro de comprar más hardware eficiente#
Hay una trampa muy común: comprar un equipo nuevo de bajo consumo para ahorrar energía sin apagar el viejo. El resultado es precioso. Ahora tienes dos servidores encendidos.
Antes de comprar otro mini PC, yo haría números muy simples. Si el equipo nuevo ahorra 15 W frente al viejo y está encendido todo el año, hablamos de unos 131 kWh al año. Multiplica por tu precio real de electricidad. Puede ser dinero, sí. Pero si el mini PC cuesta 400 euros, igual necesitas varios años para justificarlo solo por consumo.
Otra cosa es que el equipo nuevo también reduzca ruido, calor, fallos, tamaño y mantenimiento. Ahí la compra puede tener sentido. Pero conviene llamarlo por su nombre. No siempre estamos ahorrando. A veces estamos comprando comodidad, orden y ganas de tocar el rack otra vez.
No pasa nada. Pero saberlo evita autoengaños.
mi arquitectura ideal de bajo consumo#
Si tuviera que plantear un homelab doméstico eficiente desde cero, no empezaría por un cluster grande. Empezaría por tres piezas.
Una pieza siempre encendida para servicios ligeros. Mini PC eficiente, NVMe, RAM suficiente, Docker o Proxmox con pocas VMs. Aquí vivirían DNS secundario, reverse proxy interno, monitorización mínima, automatizaciones pequeñas, RSS, marcadores, algún servicio web y utilidades.
Una pieza de almacenamiento serio. NAS, Unraid, TrueNAS o un servidor con discos bien planteados. No intentaría que fuese el sitio donde pruebo cualquier locura. Guardaría datos, backups, medios y documentos. Si además corre algunos servicios cercanos a los datos, vale, pero con cabeza.
Una pieza de laboratorio apagable. Puede ser otro mini PC, un nodo Proxmox, un cluster pequeño o incluso una VM potente que levanto cuando toca. Aquí rompería cosas sin remordimientos. Si se apaga, la casa ni se entera.
Con eso ya tienes muchísimo. Si después necesitas alta disponibilidad real, la añades donde tenga sentido. No antes.
cómo decido si algo se queda 24/7#
Uso cuatro preguntas.
La primera: ¿alguien de casa lo nota si se cae? Si la respuesta es sí, sube de categoría.
La segunda: ¿pierdo datos si está apagado? Un servicio de fotos, sincronización o backups puede necesitar estar disponible en ciertos momentos. Un panel de métricas no.
La tercera: ¿me ayuda a reparar otros problemas? DNS, VPN, gestor de contraseñas y monitorización mínima pueden justificar estar arriba porque son herramientas de recuperación.
La cuarta: ¿lo he usado en los últimos 30 días? Si no, probablemente no necesita estar encendido. Quizá ni instalado.
Esta última pregunta limpia mucho. El homelab acumula servicios como un cajón de cables. “Igual lo uso” es una frase peligrosa. A veces la respuesta adulta es apagarlo y apuntar cómo volver a levantarlo si hace falta.
verano, ruido y calor#
El consumo no es solo dinero. En verano, cada vatio termina siendo calor dentro de casa. Un servidor que en invierno parece razonable puede convertirse en una pequeña estufa absurda en julio. Si además está en un despacho o armario mal ventilado, el problema se nota.
Aquí los mini PCs ganan mucho. No por magia, sino porque permiten repartir o reducir cargas sin meter un servidor empresarial en casa. Pero también tienen límites. Muchos mini PCs manejan bien CPU, RAM y NVMe, pero no siempre son agradables con discos de 3.5 pulgadas, muchas unidades, tarjetas PCIe raras o cargas sostenidas con calor.
Por eso no me obsesionaría con que todo sea mini PC. Bajo consumo no significa miniaturizarlo todo. Significa poner cada carga en el sitio menos tonto.
snapshots, backups y apagados programados#
Si vas a apagar nodos, piensa antes en las copias. No tiene sentido programar backups a las 03:00 si el destino duerme desde las 02:00. Tampoco tiene sentido apagar un nodo de laboratorio si todavía recibe sincronizaciones o trabajos nocturnos.
Yo separaría los apagados en dos grupos.
Apagado manual para laboratorio. Lo enciendo cuando lo necesito y lo apago cuando termino. Sin épica.
Apagado programado para cosas predecibles. Por ejemplo, un servidor de backup que despierta, recibe copias, verifica lo mínimo y vuelve a dormir. Esto puede ahorrar bastante, pero solo si el proceso está probado. Si falla en silencio, has construido una máquina de tranquilidad falsa.
La verificación mínima importa. No basta con que el job diga “ok”. Quiero saber que el destino estaba montado, que entraron datos nuevos y que puedo listar o restaurar una muestra. Pequeño, simple, repetible.
la parte incómoda: menos juguetes#
La reducción de consumo obliga a admitir algo un poco feo: parte del homelab existe porque nos gusta tenerlo, no porque haga falta. Está bien. El hobby también cuenta. Pero mezclar hobby con servicios familiares sin marcar límites acaba mal.
Mi forma de arreglarlo sería pactar conmigo mismo qué es infraestructura y qué es ocio técnico. La infraestructura se mantiene aburrida. El ocio técnico se enciende, se rompe, se reinstala y se apaga.
Cuando separas esos mundos, el bajo consumo sale casi solo. No porque el hardware sea milagroso, sino porque dejas de alimentar piezas que no necesitaban estar vivas.
conclusión#
Un homelab de bajo consumo en 2026 no se diseña comprando el cacharro más eficiente y rezando. Se diseña quitando importancia a lo que no la tiene.
Apagaría laboratorio. Consolidaría servicios pequeños. Mantendría el almacenamiento con respeto. No recortaría en backups, red mínima ni documentación. Y antes de comprar otro mini PC, miraría si el problema real es consumo o acumulación.
La mejor mejora de eficiencia no siempre está en el enchufe. A veces está en borrar un servicio que nadie usa, apagar un nodo que solo alimentaba ego técnico y dejar que lo importante respire.