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.
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.
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.
Durante mucho tiempo tuve Proxmox con varios nodos pero sin HA configurado. Cada nodo vivía su vida: si se caía el nodo donde estaba corriendo mi agente de Gemology, ese servicio desaparecía hasta que yo me daba cuenta y lo encendía manualmente. Con dos o tres VMs es tolerable. Con más de diez servicios corriendo, te quedas sin noches tranquilas.
Proxmox High Availability es el mecanismo que permite que cuando un nodo falla, las VMs que tenía ese nodo se reinicien automáticamente en los nodos que siguen vivos. No es migración en caliente, que eso requiere hardware y configuración diferente. Es reinicio: la VM se apaga en el nodo que falla y se arranca en otro nodo del cluster. Para la mayoría de servicios del homelab, eso es suficiente.
Dejé Dropbox después de que subieran el precio por tercera vez y la versión gratuita pasara a limitar el número de dispositivos. No fue una decisión difícil, pero sí me obligó a buscar una alternativa real, no solo otro servicio de nube con mejor precio.
La diferencia con lo que buscaba era simple: quería que mis archivos fueran de un dispositivo a otro directamente, sin pasar por un servidor de nadie. No porque tenga algo que ocultar, sino porque prefiero no depender de que una empresa decida cuánto cobrar el año que viene.
Tengo la tendencia de añadir servicios al homelab más rápido de lo que los documento. En algún momento dejé de saber de memoria qué estaba corriendo en qué servidor, en qué puerto, y con qué URL accedía a cada cosa. El día que quise mostrarle el homelab a un amigo me quedé en blanco intentando recordar la URL de Grafana.
Eso me llevó a buscar un dashboard. Probé cosas durante un tiempo, desde soluciones muy básicas (una página HTML estática con links) hasta Heimdall y Homer, que son los más conocidos. Heimdall tiene buena pinta pero me pareció demasiado manual. Homer es sólido pero vive en un YAML y cada cambio requiere editar el fichero y recargar.
Tuve una historia de amor y odio con los backups durante años. Amor porque siempre tenía la intención de montarlo bien. Odio porque cada solución que intentaba tenía algo que me echaba atrás: demasiado complicada, demasiado lenta, imposible de verificar, o que dejaba de funcionar en silencio durante semanas sin que yo me enterara.
Rsync para hacer copias de directorios. Duplicati con su interfaz web que prometía mucho y entregaba poco. Borg Backup, que es técnicamente excelente pero que tiene una curva de aprendizaje suficientemente pronunciada como para que lo dejara a medias dos veces.