Durante años usé 1Password. Buena app, buen diseño, funciona en todas partes. Pero tiene un precio que sube cada año, y con el tiempo me fui incomodando con la idea de que mis contraseñas viven en los servidores de otra empresa. No porque desconfíe de 1Password en particular, sino porque prefiero no depender de servicios externos para algo tan crítico.
Vaultwarden lleva dos años en mi homelab y no ha fallado una sola vez.
Antes de Tailscale tenía un servidor WireGuard en casa. Funcionaba, pero mantenerlo era un trabajo constante: añadir peers a mano, gestionar claves, actualizar la configuración cada vez que un dispositivo cambiaba de IP. Cuando lo dejé de lado durante tres semanas y volví a intentar conectarme desde fuera, tardé una hora en recordar cómo había configurado todo.
Eso fue hace dos años. Desde entonces uso Tailscale y no he mirado atrás.
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.
Tenía Netdata. Luego tuve Prometheus con Grafana. En algún momento llegué a tener los dos corriendo a la vez porque no me decidía a migrar del todo. Los dos hacen bien su trabajo, pero los dos tienen el mismo problema: son herramientas grandes, con mucha configuración, y cuando tienes más de cinco servidores, mantener esa infraestructura de monitorización ya se convierte en un trabajo aparte.
Hace unos meses empecé a ver Beszel en varios foros de homelab. La propuesta es distinta: un hub central que recoge métricas de agentes ultra-ligeros instalados en cada máquina. Sin bases de datos externas, sin configuración de exporters, sin Grafana necesario. El hub guarda los datos internamente con SQLite, y la interfaz web ya viene incluida.
Tengo un servidor de Gitea funcionando desde hace tiempo. Lo usé durante años para alojar código personal, scripts del homelab, y configuraciones. Cuando apareció Forgejo como fork de Gitea, al principio lo ignoré. Otro fork más. Luego fui leyendo más sobre el tema y terminé migrando.
La historia es la siguiente: en 2022, los mantenedores principales de Gitea crearon una empresa, Gitea Ltd., que asumió el control del proyecto y de la marca. Parte de la comunidad de contribuidores lo vio como un cambio de gobernanza problemático, crearon un fork llamado Forgejo bajo la Software Freedom Conservancy para mantener el proyecto gobernado por la comunidad de forma transparente. El código inicial es el mismo, pero los caminos están divergiendo.
Durante mucho tiempo usé Telegram para las notificaciones del homelab. Tenía un bot que me mandaba mensajes cuando terminaba un backup, cuando se caía un servicio, o cuando algún script de automatización fallaba. Funcionaba bien, pero dependía de la API de Telegram, necesitaba mantener el token del bot, y ocasionalmente Telegram tenía algún problema de conectividad que retrasaba las alertas.
Descubrí Ntfy buscando una alternativa y me quedé con él en dos días. La idea es tan simple que al principio no me lo creía: un servidor HTTP que actúa de broker de mensajes. Publicas en un topic con un POST, y cualquier cliente suscrito a ese topic recibe la notificación. Sin cuentas, sin OAuth, sin configuración compleja.
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.
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.
