Imagínate que Richard Hendricks de Silicon Valley aparece con su algoritmo de compresión y lo aplica al KV cache de los LLMs. Más o menos eso es lo que acaba de presentar Google Research en ICLR 2026. Se llama TurboQuant y, si corre en tu hardware, es básicamente un upgrade gratuito.
El problema que nadie te había contado bien # Cuando ejecutas un modelo de lenguaje grande —ya sea un Llama 3.3 70B o un Qwen 2.5 32B en tu homelab— el cuello de botella no es lo que imaginas. No es la velocidad de procesamiento del transformer, ni los pesos del modelo. Es el KV cache.
Portainer lo usé durante un par de años. Es una herramienta sólida, madura, y que hace cosas que Dockge no hace, como gestionar Kubernetes, gestionar nodos Docker Swarm, o tener control de acceso por roles. Si gestionas infraestructura de empresa o un cluster complejo, tiene sentido.
En un homelab personal, sin embargo, Portainer me empezó a resultar pesado. No por los recursos, que son mínimos, sino por el modelo mental. Portainer quiere gestionar tus contenedores, tus redes, tus volúmenes, tus imágenes. Tiene su propia capa de abstracción por encima de Docker. Y cuando algo no va como esperas, a veces es difícil saber si el problema está en tu configuración, en Portainer, o en Docker.
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.
Empecé con Zapier como todo el mundo. Luego pasé a Make (antes Integromat) cuando los precios de Zapier me parecieron excesivos para lo que usaba. Y finalmente llegué a n8n, lo monté en mi homelab, y desde entonces no he vuelto a pagar por ningún servicio de automatización cloud.
Esto no es una comparativa superficial. Llevo más de un año con n8n en producción, tengo más de 40 workflows activos, y he migrado casi todo lo que antes hacía en Make. Te cuento lo que funciona, lo que no, y cómo montarlo sin complicarte la vida.
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.
