// APAGAR DOCKER NO APAGA EL ENCHUFE
¿Merece la pena apagar el servidor por la noche?
Medimos un servidor casero en reposo y calculamos qué ahorras al apagarlo por la noche. Contenedores parados no es host apagado.
- #servidor-casero
- #consumo
- #docker
- #ahorro
- #homelab
Esta mañana medí 2,091 W de paquete con once contenedores levantados. La tentación es multiplicar por horas, poner dos decimales en euros y dar el asunto por resuelto. Sería una cuenta muy limpia y bastante tramposa: RAPL mide el paquete del procesador, no lo que cobra el contador de casa.
La lectura sí sirve para desmontar una confusión habitual al hablar de apagar el servidor por la noche. Parar Docker no apaga la placa, la RAM, los discos ni la fuente. El suelo sigue ahí. Si quieres borrar ese suelo durante ocho horas, tienes que suspender o apagar la máquina completa.
Lo que medí antes de tocar nada
Esperé a que terminara el trabajo pesado y tomé una muestra de 20 segundos el 31 de agosto de 2026. El host llevaba más de dos días encendido. Había once contenedores, 10 GiB de memoria disponible y el sensor térmico marcaba 53 °C. La carcasa estaba templada en la zona de las ranuras, sin ese punto casi quemante que deja un transcode largo.
timestamp=2026-08-31T09:35:58+00:00
up 2 days, 1:42, load average: 5.38, 5.48, 5.53
containers=11
Mem: 15Gi total · 5.2Gi used · 10Gi available
temp_mC=53000
rapl_package_20s=2.091 WEl load average era más alto de lo que me gusta para llamarlo reposo perfecto. Quedaban procesos de Chromium de una revisión visual y Rclone seguía vivo. Por eso no convierto esos 2,091 W en consumo total del equipo ni los comparo con una ficha comercial. Es una lectura estrecha del paquete de CPU. Demuestra que gastaba poco pese a tener los servicios levantados, nada más.
Me mordió además una tontería muy de laboratorio: el primer intento falló con Permission denied en /sys/class/powercap. El contador RAPL ahora solo lo lee root. Repetí la toma con sudo -n, sin cambiar permisos del sistema para dejar bonito un artículo.
La cuenta honesta de ocho horas
Para saber cuánto ahorras al apagar de verdad necesitas una medida en pared. Llama P a esos vatios y usa esta cuenta:
ahorro anual (kWh) = P × 8 horas × 365 / 1000Si el equipo completo marca 10 W en el enchufe, ocho horas apagado eliminan 29,2 kWh al año. A 20 W, 58,4 kWh. No fijo el precio de la electricidad porque cambia por tarifa, impuestos y fecha; la calculadora de consumo del servidor deja meter tus vatios, horas y coste real del kWh.
| Lectura en pared | Energía evitada en 8 h cada noche | Lectura útil |
|---|---|---|
| 5 W | 14,6 kWh/año | El ahorro absoluto es pequeño |
| 10 W | 29,2 kWh/año | Mini PC y almacenamiento ligero |
| 20 W | 58,4 kWh/año | Conviene mirar discos, fuente y tareas nocturnas |
| 50 W | 146 kWh/año | Aquí sí revisaría horario y necesidad 24/7 |
Son escenarios matemáticos, no mediciones de cuatro equipos. El número bueno es el de tu vatímetro. Tampoco uses el TDP del procesador como sustituto: no cuenta la máquina completa y describe un límite térmico, no una factura.
Parar servicios ahorra RAM; no necesariamente luz
La foto de docker stats fue más reveladora por memoria que por CPU. Immich Server ocupaba 870,9 MiB y su componente de aprendizaje automático 334,9 MiB. El propio blog estaba en 6,156 MiB. Apagar los tres por igual porque «son contenedores» sería una manía administrativa, no una política de ahorro.
Ahí sí veo sentido al arranque bajo demanda. Un servicio pesado, esporádico y que tolera unos segundos de espera puede devolver bastante RAM al sistema. Sablier existe justo para despertar contenedores cuando llega una petición. La documentación oficial explica el proveedor Docker y Atareao ya tiene un tutorial en español que no voy a reescribir peor.
Lo que no metería en ese juego es la VPN, la domótica o el DNS local. Son servicios pequeños cuyo valor consiste en estar disponibles. Tampoco dormiría una base de datos sin entender antes qué cliente la despierta y qué ocurre con la primera conexión. Un domingo perdí más tiempo persiguiendo una dependencia que el que habría tardado en dejar sus 30 MiB tranquilos durante años.
Qué apagaría y qué dejaría quieto
Primero movería a horario las cargas que trabajan solas: indexado de fotos, copias, análisis multimedia y modelos que no necesito de madrugada. Eso reduce picos y ruido de disco, aunque el host continúe encendido.
Después probaría suspensión completa solo si la casa puede tolerarla. Un servidor que guarda archivos personales y nada más puede dormir ocho horas. El que mantiene WireGuard, automatizaciones o grabaciones no. Para esos casos prefiero atacar la base: discos que no giren sin necesidad, una fuente decente y hardware proporcionado. La guía sobre cuánto cuesta dejar el servidor encendido explica esa diferencia sin confundir vatios con TDP.
Hay otro coste que la tabla eléctrica no recoge: los arranques. Un contenedor que tarda medio minuto y falla uno de cada veinte despertares no está ahorrando; está moviendo el mantenimiento a la primera petición de alguien. Antes de automatizar nada haría tres pruebas en frío y miraría dependencias, logs y comportamiento tras un corte.
Mi criterio después de medirlo
No apagaría contenedores ligeros para sentir que optimizo. Si falta RAM, dormiría los servicios grandes y prescindibles. Si quiero ahorrar electricidad, mediría el equipo entero en pared y decidiría si puede apagarse de verdad durante una franja estable.
En un mini PC frugal, la diferencia puede ser tan pequeña que prefiera pagarla a perder VPN y automatizaciones. En una torre vieja con discos girando, ocho horas sí cambian la cuenta. La pregunta no es cuántos contenedores hay. Es qué parte del consumo desaparece cuando pulsas apagar.
Mediciones ejecutadas el 31 de agosto de 2026 en un Intel N100 de Homelabista. docker stats es una captura instantánea; RAPL cubre el paquete de CPU y no equivale a consumo en pared.