Versionar configuraciones en un homelab tiene sentido cuando ayuda a reconstruir, auditar y tocar menos de memoria. La clave está en no meter secretos, no automatizar a ciegas y no convertir cada cambio pequeño en un ritual.
Una ventana de mantenimiento doméstica no tiene que parecer un cambio de banco. Pero si tu homelab sostiene cosas de casa, tocarlo a lo loco es una forma bastante rápida de convertir el hobby en un problema.
Un servicio puede estar encendido y estar roto. Los healthchecks buenos no miran solo si un puerto responde, comprueban que la función que importa sigue viva.
Actualizar no termina cuando el comando acaba. Termina cuando sabes que lo importante sigue respondiendo. Estas son las pruebas simples que automatizo para no descubrir fallos al día siguiente.
Un runbook casero no tiene que parecer documentación de empresa. Tiene que salvarte cuando DNS no resuelve, el backup falla o una VM crítica no arranca y tú no estás para pensar fino.
Documentar un homelab no va de hacer una wiki preciosa. Va de poder arreglar algo cuando estás cansado, saber qué depende de qué y no descubrir demasiado tarde que nadie apuntó dónde vivían los datos.
Actualizar contenedores automáticamente suena cómodo hasta que rompe algo que usa la casa. Mi enfoque: automatizar lo de bajo riesgo, revisar lo crítico y tener una política simple antes de tocar nada.
Ansible puede ser una maravilla en casa, pero también una capa de burocracia para cinco servidores que cambian cada semana. La clave está en automatizar lo aburrido, no todo.
Hay una clase de fallo que me parece bastante peor que un error claro. El fallo silencioso. El que no rompe con estruendo, no manda una alarma espectacular y no te deja un log rojo diciendo “esto ha salido mal”. Solo sigue adelante, aparenta normalidad y mientras tanto te está preparando una hostia para más tarde.
Eso fue exactamente lo que me obsesionó con mis backups por NFS. El problema no era que el backup remoto se cayera. Eso puede pasar. El problema era algo más traicionero. El montaje remoto no estaba donde debía, el script aún tenía un camino alternativo local, y la combinación de ambas cosas podía convertir una copia supuestamente segura en un proceso bastante eficiente llenando el disco del host.
Hay una fase bastante cutre en casi todo homelab con Proxmox. La de decirte a ti mismo que levantar una VM nueva son cinco minutos y luego echar media hora repitiendo siempre lo mismo. Crear la máquina, montar ISO o importar imagen, tocar red, meter clave SSH, actualizar paquetes, instalar cuatro utilidades, corregir alguna tontería del hostname y cruzar los dedos para no haber dejado un usuario raro o una configuración vieja de otra prueba. No es un drama, pero tampoco es serio.
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.