// MENOS CONTENEDORES, MEJOR ELEGIDOS
Qué merece la pena autoalojar (y qué dejar en la nube)
Qué servicios merece la pena autoalojar y cuáles dejar en la nube, con una matriz práctica y mediciones reales de un servidor casero.
- #self-hosting
- #servidor-casero
- #docker
- #privacidad
- #mantenimiento

El servidor arrancó esta mañana con once contenedores. La cifra queda estupenda en una captura, pero no dice si estoy resolviendo once problemas o coleccionando once formas de pasar el domingo mirando logs.
Antes de escribir esto tomé una lectura del N100 que uso para servicios domésticos. Los contenedores sumaban 1.770,35 MiB de memoria y un 1,61 % de CPU instantánea; el sistema conservaba 11 GiB disponibles. Plex, que corre fuera de Docker, añadía 163.840.000 bytes. El hardware iba sobrado. Mi tiempo, como de costumbre, no viene con ampliación de RAM.
Esa es la criba que falta en muchas listas de aplicaciones self-hosted. Que algo quepa en Docker no significa que merezca vivir en casa. Yo lo decido mirando qué ocurre cuando se cae, qué datos guarda y cuánto cuesta restaurarlo. Después elijo programa.
Mi regla: privacidad alta, tolerancia a fallos razonable
Autoalojaría primero aquello que guarda datos personales y puede estar unas horas fuera de servicio sin arruinarme el día. Fotos, documentos, domótica y reproducción multimedia encajan bastante bien. Si Immich se para mientras arreglo una actualización, la cámara del móvil sigue conservando las fotos. Si Jellyfin no abre, nadie pierde un contrato.
El correo es el contraejemplo perfecto. Tiene datos sensibles, sí, pero necesita entregabilidad, reputación de IP, DNS bien afinado y disponibilidad continua. Un fallo silencioso no muestra una página roja: deja mensajes ajenos sin llegar. Para aprender es un proyecto estupendo. Para la dirección con la que recibo facturas, no me compensa.
| Servicio | Mi decisión | Lo que manda |
|---|---|---|
| Fotos familiares | Autoalojado con copia externa | Privacidad alta; la caída temporal se tolera |
| Domótica local | Autoalojado | Debe funcionar aunque falle Internet |
| Multimedia | Autoalojado | Mucho almacenamiento y poco impacto si para |
| Contraseñas | Híbrido y muy conservador | Datos críticos; exportación y recuperación obligatorias |
| Correo principal | Gestionado | Entregabilidad y fallos difíciles de detectar |
| Documentos compartidos con clientes | Gestionado o híbrido | Disponibilidad y colaboración pesan más que cacharrear |
«Híbrido» no es una salida diplomática. Significa que el servicio vive en casa, pero hay una ruta independiente cuando el servidor no responde: exportación cifrada, copia fuera de casa o acceso alternativo. Si la única copia de tus contraseñas está dentro del equipo al que necesitas entrar para arreglar el equipo, has construido un chiste bastante malo.
El dato real: el servidor no es el cuello de botella

Esta fue la salida tomada el 24 de agosto de 2026, después de estabilizar el arranque:
2026-08-24 09:32:09 UTC
up 3 hours, 13 minutes
Mem: 15Gi 4.2Gi 6.0Gi 68Mi 5.6Gi 11Gi
Swap: 4.0Gi 0B 4.0Gi
containers=11 cpu_snapshot=1.61% memory_sum=1770.35MiB
La suma incluye Immich, WireGuard, Portainer, SearXNG, el propio blog y varios auxiliares. Es una fotografía de docker stats, no una media. Tampoco mide vatios en el enchufe. Sirve para una conclusión estrecha: en ese instante, añadir o quitar una aplicación ligera no iba a resolver un problema de CPU o RAM.
Plex estaba activo como servicio de sistema y quedaba fuera de esa suma:
active
MemoryCurrent=163840000
ActiveEnterTimestamp=Mon 2026-08-24 06:19:41 UTC
Lo que sí crece con cada servicio es la superficie operativa. Otra base de datos que copiar, otro formato de exportación, avisos de seguridad, una actualización que cambia el esquema y un puerto que no debería asomarse a Internet. Eso no sale en free -h.
Cuatro preguntas antes del docker compose up
No es una duda inventada para rellenar calendario: en r/selfhosted aparecieron casi seguidas una reflexión sobre las etapas por las que pasa quien empieza a autoalojar y la pregunta de un principiante sobre cómo proteger todo lo que acaba de publicar. El patrón se repite: primero instalamos; después descubrimos que cada servicio necesita una política.
Empiezo por la restauración: si mañana desaparece este contenedor, sé volver? No vale «tengo el volumen». Quiero saber dónde está la base de datos, si necesita un volcado consistente y si he probado a leer la copia. En la guía de backup 3-2-1 restauré un fichero de verdad porque un job verde solo demuestra que el job terminó.
Después miro la dependencia. Home Assistant tiene sentido local precisamente porque las luces no deberían esperar a que vuelva la operadora. Un buscador privado puede caerse y dejo de usarlo un rato. Una agenda compartida por varias personas empieza a doler mucho antes.
La tercera pregunta es de seguridad: ¿necesita estar publicado? Para administrar el homelab uso WireGuard; no voy abriendo paneles uno a uno. Un servicio que solo funciona si expongo un panel de administración sin tener claro proxy, autenticación y actualizaciones se queda en la libreta.
La última es menos técnica y más honesta: ¿me interesa mantenerlo dentro de seis meses? Montar algo el sábado es entretenido. Migrarlo un martes porque el disco da errores es el precio real.
Qué montaría primero en un servidor casero
Para empezar elegiría un servicio que dé valor incluso sin Internet y cuyo fallo sea reversible. Un bloqueador DNS local o WireGuard enseñan red sin cargar datos irrepetibles. Después vendrían multimedia y automatizaciones. Las fotos entran cuando el backup ya existe, no cuando aparece una portada bonita de Immich.
No empezaría por correo, una nube documental para terceros ni un gestor de contraseñas sin exportación probada. Tampoco copiaría una lista de veinte aplicaciones porque el N100 pueda moverlas. Puede. Ese no es el examen.
El equipo tampoco necesita ser grande. Para contenedores ligeros, un N100 con memoria suficiente tiene margen de sobra; para fotos con aprendizaje automático, muchas cámaras o varias máquinas virtuales cambia la película. La guía para elegir un servidor casero barato separa esos escalones y la calculadora de consumo 24/7 hace la cuenta con tus vatios reales. No uses el TDP como lectura de pared.
La decisión que tomaría hoy
Mantendría en casa fotos, domótica, VPN, multimedia, búsquedas privadas y automatizaciones que toleran una parada. Pagaría a un proveedor por el correo principal y por cualquier herramienta cuya caída afecte a otras personas mientras yo estoy fuera.
Y pondría una condición a cada contenedor nuevo: antes de quedarse, debe tener dueño, copia y una forma escrita de volver. Si no puedo responder esas tres cosas, no tengo un servicio. Tengo una demo que lleva demasiado tiempo encendida.
Mediciones ejecutadas el 24 de agosto de 2026 en un Intel N100 de Homelabista. CPU y memoria son lecturas instantáneas del host; no se presentan como consumo eléctrico ni como benchmark.