LLM-Gateway für KI-Agenten auf einem VPS selbst hosten

Kurz gesagt. Ein selbst gehostetes LLM-Gateway legt einen einzigen authentifizierten Endpunkt vor deine MCP-Tool-Server und LLM-Anbieter – API-Keys verlassen den Agenten-Code nie, und der gesamte Traffic bleibt auf deinem VPS. Diese Anleitung richtet zwei Dienste ein: docker-mcp-gateway für den Tool-Zugriff per MCP und LiteLLM als Modell-Router mit automatischem Fallback. Beide laufen als leichtgewichtige Docker-Container auf einem einzigen Contabo Cloud VPS.

Was ist ein selbst gehostetes KI-Agenten-Gateway?

Ein selbst gehostetes KI-Agenten-Gateway ist ein Dienst, den du auf deinem eigenen Server betreibst. Er sitzt zwischen deinen KI-Agenten und allem, was sie aufrufen müssen: MCP-Tool-Server und LLM-Anbieter. Statt dass jeder Agent eigene API-Keys und Server-Adressen hält, spricht jeder Agent mit einem einzigen Endpunkt – das Gateway übernimmt Authentifizierung, Routing und Logging.

In der Praxis kombinierst du dabei zwei Komponenten: ein MCP-Gateway für den Tool-Zugriff und ein LLM-Gateway für das Modell-Routing. Zwei Probleme erklären, warum diese Kombination sinnvoll ist. Hardcodierte API-Keys, die über Agent-Configs verstreut sind, lassen sich schwer rotieren und leicht leaken. Und jeder Agent, der direkt mit einem Anbieter oder einem MCP-Server kommuniziert, braucht eigene Verbindungslogik – sodass das Verhalten zwischen Agenten auseinanderdriftet, je größer dein Setup wird. Beide Gateways zusammen lösen das: Keys liegen an einem Ort, und jeder Agent bekommt dasselbe Verbindungs-, Retry- und Fallback-Verhalten, unabhängig davon, welches Modell oder Tool er am Ende aufruft.

Die beiden Tools in dieser Anleitung erledigen je eine Aufgabe. docker-mcp-gateway authentifiziert und routet MCP-Tool-Aufrufe. LiteLLM authentifiziert und routet LLM-Aufrufe, mit automatischem Fallback wenn ein Anbieter einen Fehler zurückgibt oder ein Rate Limit erreicht. Beide zusammen auf demselben VPS zu betreiben gibt einem Agenten ein einziges Endpunkt-Paar statt einer wachsenden Liste direkter Anbieter- und Tool-Verbindungen.

Voraussetzungen

Für das Setup eines selbst gehosteten LLM-Gateways brauchst du Folgendes, alles funktionsfähig bevor du anfängst:

• Ein Contabo Cloud VPS mit installiertem Docker. Cloud VPS 4 reicht für die Gateway-Container allein. Lies die VPS-Empfehlung weiter unten, wenn du lokale Inferenz mit Ollama hinzufügen willst.
• Docker und Docker Compose auf dem VPS installiert.
• Mindestens einen LLM-Anbieter-API-Key (OpenAI, Anthropic oder Google) – oder einen lokalen Ollama-Endpunkt, wenn du zu einem selbst gehosteten Modell routen willst statt zu einem externen Anbieter.
• SSH-Zugriff auf den VPS, idealerweise mit einem Nicht-Root-User in der docker-Gruppe.

Teil 1: Einheitliches MCP-Tool-Gateway mit docker-mcp-gateway einrichten

docker-mcp-gateway ist ein Docker-Image, das deinen Agenten authentifizierten Zugriff auf mehrere MCP-Tool-Server über einen einzigen Endpunkt gibt – ein MCP-Gateway, vollständig selbst auf deinem VPS gehostet. Es bündelt MCPHub mit einem Caddy-Reverse-Proxy, der Bearer-Token-Authentifizierung auf jede Anfrage erzwingt – mit Ausnahme des Health-Checks. Acht MCP-Server sind eingebaut: filesystem, fetch, GitHub, Brave Search, Git, PostgreSQL, memory und sequential-thinking. Kombinier es mit einem LLM-Gateway (Teil 2) und deine Agenten haben eine einzige authentifizierte Tür zu Tools und Modellen.

Container starten:

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

Beim ersten Start generiert das Gateway einen Bearer-API-Key und schreibt ihn in die Container-Logs. So rufst du ihn ab:

docker logs mcp

# oder für Scripting:
MCP_KEY=$(docker exec mcp mcp_manage --getkey)

Teste den Endpunkt. Der fetch-Server ist standardmäßig aktiviert und antwortet ohne weitere Konfiguration:

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

Eine erfolgreiche Antwort bestätigt, dass das MCP-Gateway läuft und Anfragen korrekt authentifiziert, bevor du einen Agenten verbindest.

Weitere MCP-Server aktivieren

GitHub, Brave Search und PostgreSQL benötigen eigene API-Keys oder Connection-Strings, die als Umgebungsvariablen in der Env-Datei des Containers gesetzt werden müssen, bevor diese Server aktiv werden. Keys eintragen, Container neu starten – die neu konfigurierten Server erscheinen neben den Standardservern am selben /mcp-Endpunkt. Kein separater Port, kein eigener Container pro Tool – alle aktivierten Server teilen sich den einen authentifizierten Endpunkt.

Gateway für internet-facing Deployments absichern

Für einen VPS, der vom öffentlichen Internet erreichbar ist, binde den Container an localhost statt den Port direkt freizugeben, und schalte einen Reverse Proxy mit HTTPS davor:

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

Der Bearer-Token authentifiziert weiterhin jede Anfrage, aber dieses Flag verhindert, dass der rohe Port direkt aus dem Internet erreichbar ist. Der Reverse Proxy davor übernimmt die HTTPS-Terminierung.

Teil 2: LLM-Modell-Router mit LiteLLM einrichten

LiteLLM ist ein selbst gehostetes LLM-Gateway, das einen einzigen OpenAI-kompatiblen Endpunkt bereitstellt und Anfragen an mehr als 100 Anbieter routet – darunter OpenAI, Anthropic, Gemini, Groq und Ollama. Zeig dein bestehendes OpenAI-SDK auf LiteLLMs Base-URL, und nichts in deinem Agenten-Code muss sich ändern. LiteLLM erledigt die anbieterspezifische Übersetzung im Hintergrund.

Container starten:

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

Beim ersten Start generiert der Proxy einen Master-API-Key und schreibt ihn in die Container-Logs:

docker logs litellm

# um ihn später erneut anzuzeigen:
docker exec litellm litellm_manage --showkey

Füge ein Modell mit einem Anbieter-API-Key über das eingebaute Helper-Skript hinzu. Der Proxy wendet die Änderung an und startet automatisch neu:

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-...

Als LLM-Router zeigt LiteLLM seinen wahren Wert beim Fallback-Routing: Definiere ein primäres Modell und einen Fallback in config.yaml, und LiteLLM wechselt automatisch bei einem Anbieter-Fehler oder Rate Limit – ohne dass der Agent es bemerkt.

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

Das ist der Kern dessen, was LiteLLM zu einem selbst gehosteten LLM-Gateway macht und nicht zu einem Single-Provider-Proxy: eine Config-Datei, mehrere Anbieter, automatischer Failover zwischen ihnen.

Beides verbinden: MCP-Tools und LLM-Routing auf einem VPS

docker-mcp-gateway und LiteLLM sind darauf ausgelegt, zusammenzuarbeiten. Das LiteLLM-Image von hwdsl2 stellt die Verbindung über zwei Umgebungsvariablen her statt über eine manuelle Config-Bearbeitung. Trag sie in litellm.env ein:

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

Den Key des MCP-Gateways holst du mit docker exec mcp mcp_manage --showkey, dann LiteLLM neu starten:

docker restart litellm

Beim Neustart injiziert LiteLLM automatisch einen mcp_servers-Block in seine eigene config.yaml – kein manuelles YAML-Editieren nötig. Lass beide Container im selben Docker-Netzwerk laufen, damit sie sich per Container-Name statt per öffentlicher IP erreichen:

docker network create ai-gateway

Füge --network ai-gateway zu beiden docker run-Befehlen oben hinzu und starte die Container neu. Agenten schicken Modell-Aufrufe an LiteLLM auf Port 4000, LiteLLM leitet Tool-Aufrufe an das MCP-Gateway auf Port 3000 weiter – über die LITELLM_MCP_URL-Verbindung oben. Beide Container nutzen restart=always, sodass ein VPS-Reboot das gesamte selbst gehostete LLM-Gateway automatisch wieder hochbringt – kein manueller Recovery-Schritt nötig.

Warum Contabo für ein selbst gehostetes KI-Gateway?

Beide Container sind für sich allein leichtgewichtig. docker-mcp-gateway und LiteLLM zusammen nutzen nur einen Bruchteil des RAMs eines Cloud VPS 4 (4 vCPU-Kerne, 8 GB RAM, 75 GB NVMe) – das deckt ein reines Gateway-Setup problemlos ab.

Lokale Inferenz auf derselben Maschine ändert die Rechnung. Fügst du Ollama für lokale Modelle hinzu, wird RAM zum limitierenden Faktor, nicht die CPU. Ein Cloud VPS 8 (8 vCPU-Kerne, 24 GB RAM, 200 GB NVMe) gibt genug Headroom für ein mittelgroßes lokales Modell neben beiden Gateway-Containern, ohne dass Modell und Gateways um Arbeitsspeicher konkurrieren. Die bestehende Ollama-Anleitung im Contabo Blog empfiehlt dasselbe Plan-Paar aus demselben Grund.

So oder so: Das hier ist ein selbst gehostetes LLM-Gateway, und ein KI-Gateway, das auf dieselbe Weise selbst gehostet wird, deckt auch die MCP-Tools ab. Kein Per-Request-Aufschlag durch einen Drittanbieter-SaaS-Layer, und keine Daten verlassen den VPS – außer Anfragen, die du selbst an einen externen Anbieter konfiguriert hast.

FAQ: Selbst gehostetes KI-Agenten-Gateway