Cómo autoalojar un LLM gateway para agentes de IA en un VPS

En resumen. Un LLM gateway autoalojado pone un único endpoint autenticado frente a tus servidores MCP y proveedores de LLM, de modo que las API keys nunca tocan el código del agente y todo el tráfico se queda en tu VPS. Esta guía lo configura en dos partes: docker-mcp-gateway para acceso a herramientas MCP y LiteLLM como router de modelos con failover automático. Los dos corren como contenedores Docker ligeros en un solo Contabo Cloud VPS.

¿Qué es un gateway de agentes de IA autoalojado?

Un gateway de agentes de IA autoalojado es un servicio que ejecutas tú mismo y que se sitúa entre tus agentes de IA y todo lo que necesitan llamar: servidores MCP y proveedores de LLM. En lugar de que cada agente tenga sus propias API keys y direcciones de servidor, todos hablan con un único endpoint, y el gateway se encarga de la autenticación, el routing y el logging.

En la práctica, esto combina dos piezas: un gateway MCP para el acceso a herramientas y un LLM gateway para el routing de modelos. Dos problemas explican por qué esta combinación ayuda. Las API keys hardcodeadas repartidas por las configs de los agentes son difíciles de rotar y fáciles de filtrar. Y cada agente que se conecta directamente a un proveedor o a un servidor MCP necesita su propia lógica de conexión, lo que hace que el comportamiento entre agentes se disperse conforme crece tu setup. Combinar ambos gateways resuelve esto: las keys viven en un solo lugar, y cada agente obtiene el mismo comportamiento de conexión, reintento y fallback, sin importar qué modelo o herramienta termine usando.

Las dos herramientas de esta guía hacen una sola cosa cada una. docker-mcp-gateway autentica y enruta las llamadas a herramientas MCP. LiteLLM autentica y enruta las llamadas a LLM, con failover automático si un proveedor devuelve un error o alcanza un rate limit. Ejecutar ambos en el mismo VPS le da a un agente un único par de endpoints en lugar de una lista creciente de conexiones directas a proveedores y herramientas.

Requisitos previos

Para configurar el LLM gateway necesitas lo siguiente, todo funcionando antes de empezar:

• Un Contabo Cloud VPS con Docker instalado. El Cloud VPS 4 cubre los contenedores del gateway por sí solo. Revisa la recomendación de VPS más adelante si piensas añadir inferencia local con Ollama.
• Docker y Docker Compose instalados en el VPS.
• Al menos una API key de un proveedor de LLM (OpenAI, Anthropic o Google), o un endpoint local de Ollama si vas a enrutar hacia un modelo autoalojado en lugar de un proveedor externo.
• Acceso SSH al VPS, preferentemente con un usuario sin privilegios root en el grupo docker.

Parte 1: Configura un gateway MCP unificado con docker-mcp-gateway

docker-mcp-gateway es una imagen Docker que da a tus agentes acceso autenticado a múltiples servidores MCP desde un único endpoint: un gateway MCP autoalojado en tu propio VPS. Incluye MCPHub junto con un reverse proxy Caddy que aplica autenticación con token Bearer en cada solicitud, excepto en el health check. Trae ocho servidores MCP integrados: filesystem, fetch, GitHub, Brave Search, Git, PostgreSQL, memory y sequential-thinking. Combínalo con un LLM gateway (Parte 2) y tus agentes tendrán una sola puerta autenticada para herramientas y modelos.

Inicia el contenedor:

docker run \
  --name mcp \
  --restart=always \
  -v mcp-data:/var/lib/mcp \
  -p 3000:3000/tcp \
  -d hwdsl2/mcp-gateway

En el primer arranque, el gateway genera un token Bearer y lo escribe en los logs del contenedor. Para obtenerlo:

docker logs mcp

# o, para usarlo en scripts:
MCP_KEY=$(docker exec mcp mcp_manage --getkey)

Prueba el endpoint. El servidor fetch está activo por defecto y responde sin configuración adicional:

curl http://localhost:3000/mcp \
  -H "Authorization: Bearer $MCP_KEY"

Una respuesta exitosa confirma que el gateway MCP está activo y autenticando solicitudes correctamente, antes de conectar cualquier agente.

Activa servidores MCP adicionales

GitHub, Brave Search y PostgreSQL necesitan sus propias API keys o cadenas de conexión, configuradas como variables de entorno en el archivo env del contenedor antes de que esos servidores se activen. Agrega las keys, reinicia el contenedor, y los servidores recién configurados aparecen junto a los predeterminados en el mismo endpoint /mcp. No se necesita un puerto, contenedor o gateway separado por herramienta; todos los servidores activados comparten el único endpoint autenticado.

Asegura el gateway para despliegues expuestos a internet

Para un VPS accesible desde internet, vincula el contenedor a localhost en lugar de exponer el puerto directamente y pon un reverse proxy con HTTPS delante:

docker run \
  --name mcp \
  --restart=always \
  -v mcp-data:/var/lib/mcp \
  -p 127.0.0.1:3000:3000/tcp \
  -d hwdsl2/mcp-gateway

El token Bearer sigue autenticando cada solicitud, pero este cambio evita que el puerto quede accesible directamente desde internet. El reverse proxy que va delante se encarga de la terminación HTTPS.

Parte 2: Configura un router de modelos LLM con LiteLLM

LiteLLM es un LLM gateway autoalojado que expone un único endpoint compatible con OpenAI y enruta solicitudes a más de 100 proveedores, incluyendo OpenAI, Anthropic, Gemini, Groq y Ollama. Apunta tu SDK de OpenAI existente a la URL base de LiteLLM y nada más cambia en el código de tus agentes; LiteLLM se encarga de la traducción específica por proveedor en segundo plano.

Inicia el contenedor:

docker run \
  --name litellm \
  --restart=always \
  -v litellm-data:/etc/litellm \
  -p 4000:4000/tcp \
  -d hwdsl2/litellm-server

En el primer arranque, el proxy genera una master API key y la escribe en los logs del contenedor:

docker logs litellm

# para verla más adelante:
docker exec litellm litellm_manage --showkey

Agrega un modelo con una API key del proveedor usando el script de ayuda integrado. El proxy aplica el cambio y se reinicia automáticamente:

docker exec litellm litellm_manage --addmodel anthropic/claude-3-6-sonnet-latest --key sk-ant-...
docker exec litellm litellm_manage --addmodel openai/gpt-4o --key sk-...

Como router de LLM, el verdadero valor de LiteLLM está en el routing con fallback: define un modelo primario y un respaldo en config.yaml, y LiteLLM cambia automáticamente ante un error del proveedor o un rate limit, sin que el agente lo note.

model_list:
  - model_name: primary
    litellm_params:
      model: anthropic/claude-5-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: fallback
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  fallbacks:
    - primary:
        - fallback

Esto es lo que hace de LiteLLM un LLM gateway autoalojado y no un proxy de proveedor único: un solo archivo de config, varios proveedores, failover automático entre ellos.

Conecta los dos: herramientas MCP y routing de LLM en un VPS

docker-mcp-gateway y LiteLLM están diseñados para trabajar juntos. La imagen de LiteLLM de hwdsl2 conecta ambos a través de dos variables de entorno, sin necesidad de editar la config manualmente. Agrégalas en litellm.env:

LITELLM_MCP_URL=http://mcp:3000/mcp
LITELLM_MCP_API_KEY=mcp-xxxx...

Obtén el token del gateway MCP con docker exec mcp mcp_manage --showkey, luego reinicia LiteLLM:

docker restart litellm

Al reiniciar, LiteLLM inyecta automáticamente un bloque mcp_servers en su propio config.yaml, sin necesidad de editar el YAML a mano. Ejecuta ambos contenedores en la misma red Docker para que se comuniquen por nombre de contenedor en lugar de IP pública:

docker network create ai-gateway

Agrega --network ai-gateway a los dos comandos docker run anteriores y reinicia cada contenedor. Los agentes envían llamadas a modelos a LiteLLM en el puerto 4000, y LiteLLM reenvía las llamadas a herramientas al gateway MCP en el puerto 3000, usando la variable LITELLM_MCP_URL configurada arriba. Los dos contenedores usan restart=always, así que un reinicio del VPS levanta todo el LLM gateway autoalojado por su cuenta, sin ningún paso de recuperación manual.

¿Por qué usar Contabo para un gateway de IA autoalojado?

Los dos contenedores son ligeros por sí solos. docker-mcp-gateway y LiteLLM juntos usan una pequeña fracción de la RAM de un Cloud VPS 4 (4 núcleos vCPU, 8 GB RAM, 75 GB NVMe), suficiente para un setup exclusivo de gateway.

Ejecutar inferencia local en la misma máquina cambia el cálculo. Si agregas Ollama para modelos locales, la RAM pasa a ser el factor limitante, no la CPU. Un Cloud VPS 8 (8 núcleos vCPU, 24 GB RAM, 200 GB NVMe) da margen suficiente para un modelo local de tamaño mediano junto a los dos contenedores del gateway, sin que el modelo y los gateways compitan por memoria. La guía de configuración de Ollama en el blog de Contabo recomienda el mismo par de planes por la misma razón.

En cualquier caso, esto es un LLM gateway autoalojado, y un gateway de IA autoalojado del mismo modo cubre también las herramientas MCP: sin cargo por solicitud de una capa SaaS de terceros y sin datos que salgan del VPS, a menos que una solicitud vaya a un proveedor externo que tú mismo configuraste.

Preguntas frecuentes: gateway de agentes de IA autoalojado