Durante meses my “sistema de logs” era SSH al servidor, docker logs nombre-del-container y rezar para encontrar el error antes de perder la paciencia. Cuando algo fallaba a las 3 de la mañana y me despertaba una alerta, el proceso era: conectarme, buscar en logs, no encontrar nada relevante porque el container había reiniciado y los logs anteriores habían desaparecido, rendirse.
Loki lo cambió. No es el sistema de logs más potente del mercado, pero para un homelab es perfecto: consume poco, se integra directamente con Grafana y funciona bien con Kubernetes desde el primer día.
Durante mucho tiempo ignoré los backups de mi cluster K3s. Tenía Proxmox Backup Server para las VMs, tenía el backup 3-2-1 para los datos importantes… pero el estado del propio cluster, los deployments, los ConfigMaps, los PersistentVolumeClaims: nada. Si el cluster petaba, tocaba reconstruir desde cero.
Llegó el momento en que un fallo de disco en uno de los nodos de Longhorn me dejó dos PVCs corruptos. No perdí datos críticos, pero me pasé un fin de semana reconfigurando servicios que debería haber tenido respaldados. Esa semana instalé Velero.
Durante mucho tiempo mi stack de monitorización fue Grafana más Prometheus más node_exporter más varios exporters específicos. Funciona bien, da dashboards muy potentes, y lo recomiendo. También tarda horas en configurar correctamente, tiene un consumo de recursos no despreciable, y cualquier nueva métrica que quieras monitorizar requiere buscar el exporter adecuado, configurarlo, añadir el scrape job en Prometheus, crear el panel en Grafana.
Netdata tiene una filosofía diferente. Instalas el agente y en dos minutos tienes datos de todo: CPU, memoria, disco, red, procesos, temperatura, Docker, y decenas de integraciones que se detectan automáticamente. Sin tocar ningún archivo de configuración en la instalación básica.
Este no es un post de teoría sobre IA. Es lo que realmente tengo montado, lo que ha funcionado, lo que no, y por qué creo que la forma en que muchas empresas están aproximándose a los agentes de IA está mal planteada.
Contexto: gestiono la distribución de varias marcas de cosmética de lujo en España. Marcas con catálogos grandes (cientos de productos), terminología muy específica (ingredientes activos, protocolos de tratamiento, formaciones de terapeuta), y materiales que constantemente hay que adaptar: manuales, fichas de producto, presentaciones para clientes, contenido para redes sociales.
Llevo años peleándome con scrapers que fallan en la mitad de las webs. Curl y wget para páginas estáticas, Playwright para las que necesitan JavaScript, Selenium para las que son especialmente cabronas… y siempre el mismo problema: login. Si la página necesita que estés autenticado, la cosa se complica bastante.
La semana pasada instalé browser-use CLI y cambió bastante el panorama. No es magia, pero es la herramienta más práctica que he encontrado para automatizar el navegador desde la terminal de una forma sencilla y que además puede usar tus sesiones reales de Chrome. Sin configurar credenciales. Sin gestionar cookies manualmente.
Perdí tres meses de trabajo una vez. No en un homelab, en un servidor de producción, pero la lección se me quedó grabada. Desde entonces tengo una regla no negociable: si no hay backup verificado, no existe.
Durante mucho tiempo usé las snapshots de Proxmox como backup. Es cómodo y rápido, pero es una trampa. Las snapshots viven en el mismo almacenamiento que las VMs. Si falla el disco, pierdes las VMs y las snapshots de golpe. Eso no es un backup, es una ilusión de seguridad.
Si llevas tiempo con el homelab, en algún momento llegaste al punto donde tienes cinco o seis servicios corriendo y necesitas acceder a todos por nombre de dominio en vez de por IP y puerto. Ahí es donde entra el reverse proxy.
Los dos más populares son Nginx Proxy Manager y Traefik. Los he usado los dos en producción, en momentos distintos de la vida de mi homelab, y tengo opiniones formadas sobre cuándo usar cada uno.
Un agente de IA que monitoriza tu infraestructura, revisa el email y ejecuta comandos en tu clúster K3s. Sin SaaS, sin datos que salen de tu red. Esto es lo que monté y lo que aprendí tras meses usándolo.
Después de perder datos por un nodo caído, instalé Longhorn en mi clúster K3s. Réplicas automáticas, backups a MinIO y snapshots integrados. Esto es lo que tendrías que saber antes de que te pase lo mismo.
Llevo tres años con un Synology DS1621+ en producción. He considerado cambiarlo dos veces, y las dos veces decidí quedarme. Aquí está todo lo que aprendí sobre NAS para homelab.
Montar tu propio servidor de correo en casa es una de esas ideas que suenan increíbles a las dos de la mañana y bastante peores a las nueve de la mañana del día siguiente. Yo he estado en los dos estados mentales. Primero la ilusión de tener control total. Luego el baño de realidad cuando empiezas a pelearte con SPF, DKIM, DMARC, reputación IP, puertos bloqueados y filtros antispam que te miran con sospecha aunque no hayas hecho nada raro.
Llevo tres años gestionando clusters Kubernetes. He aprendido kubectl, helm, kustomize, escribo YAMLs dormido, y aun así… hay días que abro Rancher y respiro tranquilo. Porque sí, kubectl es potente y la terminal mola. Pero cuando son las 3 de la mañana y algo se ha caído, ver gráficos de CPU en vez de piped JSON es la diferencia entre arreglarlo en 5 minutos o perder una hora.
Rancher no te convierte en peor administrador de Kubernetes. Te convierte en uno más eficiente. Y eso es lo que vamos a montar hoy.
