Hace un par de meses, revisando los logs de un VPS mío, me encontré con algo que me dejó helado: una API key completa, en texto plano, en el output de un cron job. No la había filtrado nadie. La había filtrado yo, pegándola en un script a las 2 de la mañana porque «después la muevo a una variable de entorno».
El problema no era esa key. El problema era el patrón: tenía seis scripts distintos —publicadores automáticos, monitores, un par de tareas de mantenimiento— y cada uno llevaba su propia llave, su propio endpoint y su propia lógica de reintento. Rotar una credencial significaba tocar seis archivos, reiniciar seis servicios y rezar para no olvidar ninguno. Spoiler: siempre olvidaba uno.
Qué es un gateway, sin la parte de marketing
Un gateway de agentes es un servicio que corres tú y que se para entre tus agentes y todo lo que necesitan llamar: los servidores de herramientas (MCP) y los proveedores de modelos. En vez de que cada agente tenga sus llaves y sus direcciones, todos le hablan a un solo endpoint, y el gateway se encarga de autenticar, enrutar y dejar registro.
No es magia ni una capa nueva de SaaS. Son dos contenedores Docker en la misma máquina: uno que expone las herramientas MCP detrás de un token Bearer, y otro —LiteLLM es el más conocido— que expone un endpoint compatible con OpenAI y traduce hacia más de cien proveedores. Lo interesante es esto último: si tus agentes ya usan el SDK de OpenAI, solo cambias la URL base y no tocas una línea de código.
Lo que de verdad me sirvió: el failover
Yo esperaba que el beneficio fuera el orden. Terminó siendo la resiliencia. Mate el 3 de julio a las 4 de la mañana un proveedor se cayó a mitad de una corrida programada y, en vez de perder la tarea, el router pasó al modelo de respaldo sin que el agente se enterara. Eso, con llaves regadas en seis scripts, es imposible: cada script tendría que saber que existe un plan B.
Un detalle que se agradece: el gateway también puede inyectar solo el bloque de servidores MCP en su propia configuración, así que no andas editando YAML a mano cada vez que agregas una herramienta.
La parte que nadie te cuenta: te acabas de crear un punto único de falla
Si el gateway se cae, todo se cae. Antes, que un script muriera era un problema de un script. Ahora es el sistema completo. Por eso mismo: restart=always no es opcional, y si puedes, mételo en la misma red Docker que el resto para que se hablen por nombre de contenedor y no por IP pública.
Y esto es lo que más veo mal hecho en el mundo real: gente que levanta LiteLLM en 0.0.0.0:4000, sin contraseña, en un VPS con IP pública. Con eso no arreglaste el problema de las llaves: lo centralizaste en un puerto abierto para que lo encuentre cualquiera. La regla es simple: el contenedor escucha en 127.0.0.1 y el TLS lo pone un reverse proxy adelante. Ni un puerto directo más.
¿Conviene? Depende de cuántos scripts tengas
Para dimensionar: un gateway solo, sin modelos locales, vive cómodo en 8 GB de RAM. Si le agregas inferencia local con Ollama, la RAM pasa a ser el cuello de botella y hablamos de unos 24 GB, porque el modelo se come la memoria. Pero seamos honestos: si tienes un script y una sola llave, esto es sobreingeniería. Nadie necesita dos contenedores para eso.
Ahora, si tienes agentes corriendo solos de madrugada, con credenciales repartidas y un proveedor que a veces te deja en visto, un gateway propio deja de ser un lujo. No es solo orden: es saber exactamente qué se está gastando, con qué llave y hacia dónde salió cada solicitud. En mi caso, la clave fue aceptar que mi problema no era de código, era de secretos.
Fuente del tema: Cómo autoalojar un LLM gateway para agentes de IA en un VPS, del blog de Contabo.
Fuente de inspiración: Cómo autoalojar un LLM gateway para agentes de IA en un VPS
