Llevo tres años cambiando de hardware homelab y cometiendo los mismos errores que todos al principio. Empecé con una Raspberry Pi, di el salto a un PC viejo de torre, y después de varios recorridos y facturas de luz más altas de lo que me esperaba, llegué a los mini PCs. Hoy mi homelab principal corre sobre un Minisforum MS-01 y un par de nodos más pequeños, y estoy razonablemente contento.
Durante años fui usuario de Plex. Lo consideraba la solución definitiva para tener mi biblioteca de películas y series accesible desde cualquier dispositivo. Luego llegaron los cambios en las condiciones del servicio, la cuenta online obligatoria para acceder a tu propio servidor en red local, y la dirección cada vez más claramente orientada a convertirlo en otra plataforma de contenido de pago.
No digo que Plex sea malo. Sigue siendo muy bueno en muchas cosas. Pero cuando empecé a investigar alternativas, encontré Jellyfin y me di cuenta de que no necesito Plex para lo que yo hago.
Hay herramientas que uno descubre tarde y piensa: ¿cómo estuve tanto tiempo sin esto? Cockpit es una de ellas.
La descubrí por casualidad mientras buscaba una forma de gestionar mis servidores Debian sin tener que conectarme por SSH para cada cosa pequeña. No quería Portainer porque no todo lo que corre en mis servidores es Docker. No quería montar otra aplicación en K3s solo para ver el estado de una máquina. Quería algo nativo, ligero y que funcionara sin fricción.
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.
Hay un problema que aparece tarde o temprano cuando llevas un tiempo con el homelab: necesitas almacenamiento de objetos compatible con S3. No porque seas Amazon, sino porque muchas herramientas modernas hablan S3 de forma nativa. Velero para backups de Kubernetes. Loki para logs. Restic, Rclone, Backblaze. Incluso algunas aplicaciones como Immich o Seafile pueden usar S3 como backend.
Si dependes de AWS S3 real, tienes un coste mensual variable y tus datos en manos de Amazon. MinIO resuelve eso: un servidor de objetos que habla la misma API que S3, que corres en tu propio hardware.
Tailscale es probablemente la herramienta que más ha cambiado cómo gestiono mi homelab. La idea es simple: crea una red mesh privada entre todos tus dispositivos usando WireGuard por debajo, sin que tengas que configurar ningún firewall ni abrir puertos. Funciona detrás de NAT, funciona con CGNAT, funciona en casi cualquier sitio.
El problema es que Tailscale, la empresa, controla el servidor de coordinación. Ese servidor no ve tu tráfico (está cifrado end-to-end), pero sí gestiona la autenticación y el intercambio de claves públicas. Si Tailscale cierra, cambia precios o decide que tu caso de uso no les interesa, tienes un problema.
Durante mucho tiempo tuve el mismo problema que creo que tiene casi todo el que monta un homelab con más de cuatro o cinco servicios: una contraseña diferente para cada cosa. Proxmox con su usuario, Grafana con el suyo, Portainer con otro, y así hasta llegar a tener un documento con 20 credenciales que actualizaba de forma irregular. Cuando instalaba un servicio nuevo, pensaba un momento y escribía alguna variación de siempre la misma contraseña. Mal hábito.
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.
Tengo más SBCs repartidos por casa de lo que me gustaría admitir. Hay un par de Raspberry Pi haciendo de sensores, un ZimaBoard en el rack de red, y algún Orange Pi que empecé a usar para algo y se quedó a medias. Todos estuvieron durante meses sin carcasa, apoyados sobre su propia PCB o dentro de bolsas antiestáticas. Funciona, pero es feo y no protege nada.
La impresora 3D cambió eso. Ahora cada SBC que uso tiene su carcasa impresa, con ventilación, con soporte para el rack si hace falta, y en algunos casos con personalización que no encontrarías en ningún sitio. Llevarlo a la práctica no es complicado, pero hay decisiones de material y de diseño que marcan la diferencia entre una carcasa que dura y una que se deforma al mes.
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.
