Hay una cosa que me sigue haciendo gracia del mundo self-hosted. Montamos infra cada vez más compleja para acabar resolviendo tareas que, en el fondo, se arreglan con dos comandos bien puestos y un poco de criterio. Publicar una web estática es una de ellas.
He probado flujos más elaborados. CI/CD con más capas, builders remotos, pipelines con demasiadas piezas, deploys muy listos sobre el papel y algo menos listos cuando fallan a las dos de la mañana. Al final he vuelto a lo que mejor me funciona para proyectos pequeños y medianos que controlo yo: Hugo para generar el sitio y rsync para dejarlo en el servidor.
Cada pocos meses veo la misma idea repetida en Reddit, YouTube y foros de homelab. Si quieres un servidor de verdad, necesitas Proxmox, Linux, una caja con más bahías que sentido común y, si puede ser, un mini PC chino con cuatro puertos 2.5GbE para sentir que estás en control de tu vida. Me gustan esos cacharros, de hecho tengo varios. Pero hay una verdad menos vistosa: el equipo que más trabajo real me saca adelante sigue siendo un Mac mini M1.
La semana pasada publiqué la guía básica de Vaultwarden. Ahí contaba por qué me compensa más que seguir pagando un gestor alojado por otro y cómo dejarlo funcionando en poco tiempo. Esa parte está bien para arrancar, pero si te quedas ahí te falta lo importante.
Vaultwarden no es un servicio cualquiera. No es un dashboard más, ni un lector RSS, ni una app para ver métricas del NAS. Aquí vives con tus credenciales, tus notas seguras, tus TOTP y en muchos casos la puerta de entrada al resto del homelab. Si esto lo montas regular, el problema no es que falle una tarde. El problema es que estás haciendo malabares con la pieza más sensible de toda tu casa digital.
Hace unos días publiqué mi guía base de Tailscale. Ahí contaba por qué dejé de pelearme con WireGuard puro para el acceso diario al homelab. Esa parte sigue siendo cierta. Instalar Tailscale sigue siendo ridículamente fácil. Lo que ya no me parece tan sencillo es diseñarlo bien cuando tu red deja de ser cuatro cacharros y empieza a parecer una pequeña jungla.
Ese es el punto en el que casi todas las guías se quedan cortas. Te enseñan a hacer tailscale up, ves el dispositivo en el panel y te vienes arriba. Luego pasan dos semanas, quieres acceder a un switch que no puede instalar el cliente, quieres sacar internet por casa cuando estás de viaje, o decides que igual no te hace gracia que todos los nodos hablen con todos. Ahí empieza el trabajo real.
El año pasado perdí un disco en mi servidor de almacenamiento. No fue un fallo catastrófico con chispas y humo, fue algo peor: el disco empezó a dar errores intermitentes durante semanas, los datos se corrompieron de forma silenciosa y me di cuenta tarde. Tardé tres días en recuperar todo desde el backup, y eso fue porque tenía backup. Muchos no lo tienen.
Desde entonces uso Scrutiny en todos mis servidores. Es un servicio Docker que recopila los datos S.M.A.R.T. de todos tus discos, los analiza y te manda una alerta cuando detecta valores que deberían preocuparte. No es infalible (los discos pueden fallar sin previo aviso S.M.A.R.T.) pero en mi experiencia la mayoría de fallos vienen precedidos de semanas o meses de señales que S.M.A.R.T. detecta si alguien está mirando.
Cuando monté mi homelab hace unos años, lo primero que quería era acceder a mis servicios desde fuera de casa sin abrir puertos al mundo. Empecé con OpenVPN, que funcionaba pero era una pesadilla de configurar. Luego me pasé a Tailscale, que sigue siendo mi opción favorita para redes mesh complejas. Pero hace unos meses descubrí wg-easy, y para casos simples es lo que uso ahora.
WireGuard en sí lleva años disponible. El problema siempre ha sido la configuración. Generar claves, editar archivos de configuración manualmente, distribuir los perfiles a los clientes… no es complicado, pero tiene fricción suficiente como para que muchos lo dejen a medias. wg-easy resuelve exactamente ese problema: es un contenedor Docker que levanta WireGuard con una interfaz web desde la que puedes gestionar clientes en dos clics.
Durante un tiempo usé Watchtower para mantener los containers actualizados. Lo configuré en modo auto-update y durante unos meses fue perfecto. Luego un día me encontré con que un container había actualizado automáticamente a una versión que tenía un breaking change y me rompió el servicio.
Desde ese día tengo una política diferente: quiero saber que hay una actualización antes de aplicarla, no que se aplique sola. What’s Up Docker (WUD) cubre exactamente ese caso. Monitoriza tus containers, detecta cuando hay nuevas versiones, y te avisa. Tú decides cuándo y si actualizar.
Hace unos meses me di cuenta de que subía documentos de trabajo a ilovepdf casi cada semana. Contratos, facturas, presupuestos. Todo pasando por servidores que no controlo. No es que sea un paranoico de la privacidad, pero hay cosas que preferirías no tener en servidores de terceros.
Así llegué a Stirling PDF. Lleva un tiempo en GitHub con bastante tracción, lo había visto mencionado en varios hilos de Reddit, y un día me senté a instalarlo. Lleva meses funcionando sin problemas y lo uso casi a diario. Esto es lo que he aprendido.
Llevaba años oyendo que ZFS era la mejor decisión que podías tomar para el almacenamiento de tu homelab. Tardé demasiado en hacer el salto porque siempre me parecía que era demasiado complejo, que necesitaba hardware específico, que era “cosa de empresas”. Todo eso era mentira, pero entiendo por qué creí que era verdad.
La funcionalidad que me terminó de convencer fue los snapshots. Y este post es básicamente un argumento de por qué deberías conocerlos aunque ya tengas algún sistema de backup funcionando.
Hay una conversación que tengo con regularidad cuando alguien nuevo llega al mundo del homelab. Me preguntan: “¿uso Docker o mejor una VM?” Y la respuesta correcta suele ser “depende”, pero durante mucho tiempo me faltó mencionar una tercera opción que uso bastante: Incus.
Incus es un gestor de contenedores de sistema. No contenedores de aplicación como Docker, sino contenedores que ejecutan un Linux completo, con su propio systemd, sus propios procesos en background, su init, su cron. Desde dentro parece una VM normal. Desde fuera consume una fracción de los recursos.
Tenía un sistema de cámaras de vigilancia barato conectado a una app del fabricante que guardaba las grabaciones en su nube. Funcionaba. Veía las notificaciones, podía revisar lo que había grabado, y en general hacía lo que prometía. El problema era que no sabía exactamente qué hacía el fabricante con esas grabaciones, la app dejó de funcionar bien después de una actualización, y cuando intenté exportar mis propias grabaciones resultó que el proceso era más complicado de lo razonable.
Tengo un cajón de despacho que durante años fue la representación física del caos. Cables USB de todas las épocas, tornillos de tamaño desconocido, adaptadores de dudosa procedencia, baterías que igual están cargadas o igual llevan vacías desde 2021. Cada vez que necesitaba algo concreto tardaba cinco minutos en buscarlo y otros cinco en recordar que no estaba ahí.
Probé cajas de plástico compradas. Probé divisores de cajón de bambú. Probé sobres de plástico etiquetados. Todo funcionaba más o menos hasta que movía una cosa y el resto quedaba desordenado.
