Home Server: convertir un portátil de 2014 en infraestructura doméstica

Un home server no tiene que empezar con hardware nuevo ni con una arquitectura complicada. En este caso, el proyecto comenzó reutilizando un Mac portátil de 2014 que llevaba tiempo sin uso. El equipo ahora ejecuta Ubuntu Server 26.04 LTS y funciona como una pequeña plataforma para servicios de red, monitorización y administración doméstica.

El equipo y la red

El servidor tiene cuatro núcleos, 7,16 GB de RAM y unos 233 GB de almacenamiento. Está conectado por Wi-Fi a la red doméstica y utiliza una dirección IP fija. El router DIGI proporciona la conectividad y entrega el servidor DNS a los dispositivos mediante DHCP.

La decisión más importante fue mantener el sistema dentro de la red local. No se han abierto puertos en el router ni se ha publicado ningún servicio directamente en Internet. El objetivo actual no es construir una infraestructura de alta disponibilidad, sino disponer de servicios útiles, controlados y suficientemente documentados.

Servicios desplegados

Todos los servicios se ejecutan en contenedores Docker.

Pi-hole: DNS filtrante

Pi-hole es el servicio principal. El router anuncia Pi-hole como servidor DNS para los dispositivos de la red, de modo que las consultas pasan por un filtro común sin instalar aplicaciones adicionales en cada equipo.

La configuración utiliza los servidores DNS upstream de Cloudflare y mantiene la configuración de Pi-hole en almacenamiento persistente. El panel web utiliza HTTPS local con un certificado autofirmado. La contraseña se gestiona como secreto de Docker y se conserva fuera de las notas del proyecto.

La instalación se validó con consultas DNS normales y con dominios bloqueados. El resultado confirma que Pi-hole funciona como DNS filtrante para la LAN. Todavía falta probar de forma completa el procedimiento de rollback y restauración.

Portainer: administración de Docker

Portainer proporciona una interfaz web para consultar y administrar los contenedores y stacks Docker. Es útil para las operaciones diarias y para revisar rápidamente el estado de los servicios sin depender siempre de la terminal.

Su acceso está limitado a la red local. Antes de añadir nuevas interfaces de red, como Tailscale, habrá que revisar de nuevo qué servicios escuchan en todas las interfaces del sistema.

Uptime Kuma: disponibilidad y alertas

Uptime Kuma comprueba el estado del router, la conexión a Internet, el DNS de Pi-hole, los paneles web, SSH y la API de Netdata. Los monitores funcionan con intervalos periódicos y algunos envían alertas mediante Telegram.

Las alertas se probaron de extremo a extremo: se generó una caída controlada y después una recuperación, y ambas notificaciones llegaron correctamente. Esto permite distinguir algunos fallos de red y de servicio.

Uptime Kuma no se limita a vigilar el propio home server. También me permite monitorizar la disponibilidad de otros proyectos, como Nupzi. De esta forma puedo registrar si una aplicación responde correctamente, detectar cuándo deja de estar disponible y recibir una alerta si se produce una caída.

Su límite es importante: Uptime Kuma se ejecuta en el mismo servidor que monitoriza. Si el portátil, Docker, la alimentación o el propio Kuma fallan por completo, no puede enviar una alerta. Para cubrir ese caso hace falta monitorización externa.

Netdata: métricas del sistema

Netdata añade métricas locales de CPU, memoria, disco, red y otros componentes. El panel se validó desde otro equipo de la LAN y mostró más de 4.000 métricas junto con histórico local.

Netdata ayuda a investigar los problemas recientes de estabilidad, pero no sustituye una comprobación SMART de los discos ni una supervisión externa. También está pendiente confirmar que el histórico y el contenedor sobreviven correctamente al próximo reinicio.

Seguridad y estado actual

El firewall limita el acceso a la red local. No se guardan contraseñas, tokens ni claves privadas en el proyecto. Los certificados locales son autofirmados porque los servicios no están publicados en Internet.

Durante los días 12–13 y el 15 de septiembre se produjeron interrupciones de conectividad. Reiniciar el servidor recuperó el acceso, pero todavía no se conoce la causa. No está confirmado si falló el DNS, la red, el sistema operativo o el propio hardware.

Próximos pasos

La prioridad es estabilizar antes de añadir más servicios:

• Revisar registros, carga, memoria, swap y comportamiento después de un reinicio.
• Comprobar físicamente los discos y su estado SMART.
• Investigar el bloqueo observado al conectar HDMI.
• Crear copias de seguridad y probar una restauración real.
• Configurar una clave SSH exclusiva.
• Añadir monitorización externa para detectar una caída completa.
• Evaluar Tailscale para acceder al DNS fuera de casa sin abrir puertos.
• Decidir si merece la pena mantener el equipo, migrar los servicios o retirarlo.

El proyecto ya tiene una base funcional. La siguiente etapa no consiste en instalar más aplicaciones, sino en demostrar que los servicios pueden recuperarse, que los datos están protegidos y que una avería no deja toda la red sin diagnóstico.