LiteLLM mit Docker Compose installieren: Self-Host-Guide 2026

Hinweis: Diese Anleitung enthält Referral-Links. Wenn du darüber kaufst, erhalte ich möglicherweise eine Provision – ohne zusätzliche Kosten für dich.

In dieser Anleitung installierst du LiteLLM mit Docker Compose und machst daraus ein self-hosted LLM-Gateway: ein OpenAI-kompatibler Endpoint auf Port 4000, der sämtliche Modell-APIs bündelt, die du nutzt. Apps bekommen eine einzige Base-URL und einen Key, LiteLLM übernimmt Routing, Retries, Budgets und Logging – und deine Provider-Keys verlassen den Server nie.

LiteLLM ruft über 100 LLM-APIs auf (OpenAI, Anthropic, Bedrock, TogetherAI, lokales Ollama und mehr) über die OpenAI-API-Spec. Stand Oktober 2026 hat das Repo rund 61k GitHub-Sterne, liefert wöchentliche Releases, und der Proxy läuft auf einem Rust-Core mit Python-SDK. MIT-lizenzierter Core, Enterprise-Features obendrauf. Für das Gateway selbst brauchst du keine GPU.

Wenn du zuerst einen Reverse Proxy willst, richte Traefik ein, bevor du weitermachst.

Wenn du ein paar kostenlose, coole Open-Source-Self-Hosted-Apps sehen willst, schau dir die Self-Hosted-Sektion auf toolhunt.net an.

Was ist LiteLLM? Ein self-hosted LLM-Gateway

LiteLLM ist ein Proxy und SDK, das jeden LLM-Provider, den du nutzt, über eine einzige API im OpenAI-Format bereitstellt. Richte deine Apps auf http://litellm:4000/v1 (oder deinen Traefik-Hostnamen) und wechsle Provider, indem du eine YAML-Datei bearbeitest – nicht den Anwendungscode.

Das ist das Betreiber-Argument. Ohne Gateway hält jede App rohe Provider-Keys, jede App braucht ihre eigene Retry- und Fallback-Logik, und du erfährst von den Kosten erst mit der Rechnung. Mit LiteLLM dazwischen liegen Key-Rotation, Usage-Logging, Budgets und Modell-Aliase an einem Ort. Clients authentifizieren sich gegen dein Gateway, nie direkt gegen OpenAI oder Anthropic.

LiteLLM-Gateway-Request-Flow: Clients und Agents erreichen Traefik über TLS, LiteLLM auf Port 4000 routet zu OpenAI, Anthropic oder lokalem Ollama, mit optionalem Postgres-Container für Virtual Keys, Budgets und Spend-Logs

Ein Lizenz-Hinweis, bevor du dich festlegst: Der Core ist MIT, und das Repo enthält Enterprise-Features unter einer separaten Lizenz. Das Docker-Image und alles in dieser Anleitung laufen auf dem offenen Pfad. Lies die Lizenzdateien im Repo, wenn du es in ein kommerzielles Produkt einbetten willst.

Die wichtigsten Features von LiteLLM

Was du bekommst, sobald es läuft:

Beim Durchsatz werde ich keine RPS-Zahl nennen. LiteLLM veröffentlicht Load-Test-Ergebnisse in den Docs, aber was du bekommst, hängt von deinen Modellen und der Upstream-Latenz ab, nicht vom Proxy. Rechne damit, dass das Gateway günstig zu betreiben ist und die Provider-Calls der teure Teil sind.

LiteLLM-Deploy-Optionen: Ohne Datenbank vs. mit Postgres

Es gibt zwei Wege, den Compose-Stack zu betreiben, und die Wahl ist wichtiger als früher.

Noch eine Korrektur zu der alten Anleitung da draußen: Das Gateway braucht weder GPU noch eine große Maschine. Es proxied API-Calls, es führt keine Inferenz aus. Ein VPS mit 2 vCPU / 2–4 GB reicht für den Proxy selbst locker; GPU-Hardware wird nur relevant, wenn du Ollama daneben stellst. Wenn du diesen Weg gehst, schau dir den besten Mini-PC für lokale LLMs und Ollama an oder einen kompakten Mini-PC, wenn du etwas Leises unterm Schreibtisch willst.

Die VPS-Preise sind 2026 überall gestiegen. Wenn du eine gemietete Maschine neu überdenkst, schau dir an, was sich geändert hat und wann ein Mini-PC gewinnt.

LiteLLM mit Docker Compose installieren (ohne Datenbank)

Das ist der Weg zu einem funktionierenden Gateway noch heute Abend. Die Voraussetzungen unten gelten für beide Installationswege – lies sie einmal und komm dann hierher zurück oder spring zum Postgres-Abschnitt.

Voraussetzungen

Für den VPS selbst nutze ich Hetzner für EU-Maschinen und Hostinger, wenn ich woanders günstige NVMe will. Beide stemmen einen LiteLLM-Proxy ohne ins Schwitzen zu kommen.

Falls du Server-Ressourcen wie CPU, RAM und Festplattenplatz überwachen willst, schau dir an: How To Monitor Server and Docker Resources.

LiteLLM-Config-Datei mit aktuellen Modellen

Erstelle litellm_config.yaml. Die komplette Provider-Liste liegt unter docs.litellm.ai/docs/providers (der alte litellm.vercel.app-Link ist veraltet).

model_list:
  - model_name: gpt-5.6-terra
    litellm_params:
      model: openai/gpt-5.6-terra
      api_key: os.environ/OPENAI_API_KEY
  - model_name: claude-sonnet-5
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

Zwei Felder, zwei Jobs:

• model_name ist, was Clients im "model"-Feld ihres Requests schicken. Es ist dein Alias – wähl etwas Einprägsames.
• litellm_params.model ist, was LiteLLM upstream schickt, und es nimmt einen Provider-Präfix: openai/..., anthropic/..., ollama/.... Der Präfix routet den Request zum richtigen Provider.

api_key: os.environ/OPENAI_API_KEY ist das dokumentierte Indirection-Muster. LiteLLM liest den Key aus der Container-Umgebung statt aus der Config-Datei, sodass dein YAML keine Secrets enthält und in Git liegen kann.

Docker-Compose-Datei ohne Datenbank

services:
  litellm:
    image: docker.litellm.ai/berriai/litellm:v1.105.0   # pin! ghcr.io/berriai/litellm:v1.105.0 also fine
    restart: unless-stopped
    command:
      - "--config=/app/config.yaml"
      - "--detailed_debug"
    environment:
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY:?set in .env}
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    ports:
      - "127.0.0.1:4000:4000"

Was daran wichtig ist:

• Das Image ist auf v1.105.0 gepinnt, die aktuelle Stable (veröffentlicht 2026-10-11). Betreibe keinen Floating Tag irgendwo, wo es dir wichtig ist. Mehr zu Tags im nächsten Abschnitt.
• Der Befehl setzt --config=/app/config.yaml, was der Mount-Konvention der Docs entspricht. --detailed_debug ist ausführliches Logging; wirf es raus, sobald du mit dem Troubleshooting fertig bist.
• Der Volume-Mount ./litellm_config.yaml:/app/config.yaml ist wichtig. Wenn du an einen beliebigen Pfad mountest und --config nicht aktualisierst, startet der Proxy mit einer leeren Modellliste.
• Das Port-Binding 127.0.0.1:4000:4000 hält die Host-Seite auf localhost. Traefik erreicht den Container über das Docker-Netzwerk, also gibt es keinen Grund, 4000 ins Internet zu exponieren.
• Umgebungsvariablen tragen die Provider-Keys über os.environ/... und den Master Key.

.env-Datei, neben der Compose-Datei:

LITELLM_MASTER_KEY=sk-REPLACE_ME
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-...

Generiere die komplette Datei sauber, niemals sk-1234 wiederverwenden:

echo "LITELLM_MASTER_KEY=sk-$(openssl rand -hex 32)" > .env
echo "OPENAI_API_KEY=sk-REPLACE_ME" >> .env
echo "ANTHROPIC_API_KEY=sk-REPLACE_ME" >> .env
chmod 600 .env

Hochfahren und den Container prüfen:

docker compose up -d
docker compose ps
docker compose logs -f litellm | head -50

Fehlerfälle, die man hier kennen sollte:

• Wenn Port 4000 schon belegt ist, hält ein anderer Container (oder ein lokaler Dev-Server) den Port. Ändere die Host-Seite auf 127.0.0.1:4001:4000 oder stoppe den anderen Dienst.
• Wenn die Config am falschen Pfad gemountet ist, startet der Container, aber jeder Request 404t das Modell. Prüfen mit docker compose exec litellm cat /app/config.yaml.
• Wenn der sk--Präfix im Master Key fehlt, schlägt der Start mit einer Verweigerung in den Logs fehl. Korrigiere die .env und führe docker compose up -d erneut aus.

Open WebUI + LiteLLM + Ollama als kombinierter Stack

Wenn du eine Chat-UI und lokale Modelle hinter demselben Gateway willst, ist das der kombinierte Stack. Die Open-WebUI-+-Ollama-Seite habe ich im Ollama-Docker-Compose-Setup-Guide und in OpenClaw mit Ollama betreiben behandelt; hier sitzt LiteLLM davor, damit Open WebUI auch deine Cloud-Modelle sieht.

services:
  openWebUI:
    image: ghcr.io/open-webui/open-webui:main
    container_name: openwebui
    hostname: openwebui
    networks:
      - traefik-net
    restart: unless-stopped
    volumes:
      - ./open-webui-local:/app/backend/data
    labels:
      - traefik.enable=true
      - traefik.http.routers.openwebui.rule=Host(`openwebui.domain.com`)
      - traefik.http.routers.openwebui.entrypoints=https
      - traefik.http.services.openwebui.loadbalancer.server.port=8080
    environment:
      OLLAMA_BASE_URLS: http://ollama:11434
      OPENAI_API_KEY: ${LITELLM_MASTER_KEY}
      OPENAI_API_BASE_URL: http://litellm:4000/v1
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    hostname: ollama
    networks:
      - traefik-net
    volumes:
      - ./ollama-local:/root/.ollama
  litellm:
    image: docker.litellm.ai/berriai/litellm:v1.105.0
    container_name: litellm
    hostname: litellm
    networks:
      - traefik-net
    restart: unless-stopped
    command:
      - --config=/app/config.yaml
      - --detailed_debug
    environment:
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY}
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      ANTHROPIC_API_KEY: ${ANTHROPIC_API_KEY}
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
networks:
  traefik-net:
    external: true

OPENAI_API_BASE_URL zeigt auf den LiteLLM-Container, und OPENAI_API_KEY ist der Master Key (oder ein Virtual Key, sobald du Postgres hast). Open WebUI listet dann jedes Modell aus deiner litellm_config.yaml neben den Ollama-Modellen.

Ein Ehrlichkeits-Hinweis: Die Umgebungsvariablennamen von Open WebUI driften zwischen Releases. Das OPENAI_API_BASE_URL-Muster oben ist das langjährige und entspricht der open-webui:main-Doku, Stand Oktober 2026 – aber wenn die UI das Gateway nicht erreicht, prüfe erst die aktuellen Open-WebUI-Docs auf umbenannte Variablen, bevor du LiteLLM debuggst.

Das LiteLLM-Docker-Image pinnen und Signaturen verifizieren

Dieser Abschnitt existiert, weil Floating Tags beim März-2026-Vorfall Leute gebissen haben. Mach das Pinnen zur Gewohnheit.

Das Tag-Schema seit v1.84.0 ist schlichtes SemVer. Die alten Suffixe -stable und -nightly sind weg. Wöchentliche Releases erhöhen MINOR, PATCH ist für Hotfixes reserviert, und Docker veröffentlicht sowohl nackte (1.84.0) als auch v-präfixierte (v1.84.0) Tags desselben Images. Alte v1.83.x-stable-Namen bleiben für immer veröffentlicht, also bricht nichts, was du bereits laufen hast.

• Pinne v1.105.0 (oder was auch immer aktuell ist, wenn du das liest) für alles über lokaler Evaluation hinaus.
• main-stable floatet auf die neueste Stable. Praktisch für ein Homelab-Experiment, falsch für Produktion. Es driftet unter dir weg, üblicherweise zum schlechtesten Zeitpunkt.

Registries: Der offizielle Quickstart veröffentlicht auf docker.litellm.ai/berriai/litellm, und der Security-Guide verifiziert auf ghcr.io/berriai/litellm. Beide tauchen in offiziellem Material auf. Wenn du den strengsten Pfad willst, pull und verifiziere von GHCR.

docker pull docker.litellm.ai/berriai/litellm:v1.105.0

docker pull ghcr.io/berriai/litellm:v1.105.0

cosign verify \
  --key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
  ghcr.io/berriai/litellm:v1.105.0

Image-Varianten: litellm ist der Core-Proxy und enthält jetzt die Prisma-Toolchain für Postgres, sodass es Migrationen selbst erledigt. litellm-database ist ein Legacy-Alias für dieselbe Toolchain, denselben Entrypoint und dieselben Migrationen. Es gibt keinen Grund mehr, zwischen den beiden zu wählen. litellm-non_root ist verfügbar, wenn du auf root verzichten willst.

LiteLLM mit Docker Compose und Postgres installieren

Das ist der Produktionspfad. Postgres schaltet die Admin-UI, Virtual Keys, Spend-Tracking und Config-Persistenz frei. STORE_MODEL_IN_DB: "True" ist der Schalter, der der Admin-UI und der /config/update-API sagt, sie sollen Einstellungen in die LiteLLM_Config-Tabelle schreiben statt nur dein YAML zu lesen.

Erforderliche Umgebungsvariablen: Master Key und Salt Key

Der DB-Modus braucht zwei Keys, nicht einen. Die Compose-Datei unten verweigert den Start ohne beide.

Generiere alles sauber:

printf 'LITELLM_MASTER_KEY=sk-%s\nLITELLM_SALT_KEY=sk-%s\nPOSTGRES_PASSWORD=%s\n' \
  "$(openssl rand -hex 32)" \
  "$(openssl rand -hex 32)" \
  "$(openssl rand -hex 16)" > .env
chmod 600 .env

Für UI-Härtung bei geteilten Installationen: general_settings.disable_env_credential_login: true lehnt UI_USERNAME/UI_PASSWORD/Master-Key-Logins auf der UI-Seite ab, sodass sich nur datenbankgestützte User anmelden können. Der Default-Flow ist einfacher: Username admin, Passwort = LITELLM_MASTER_KEY.

Docker-Compose-Datei mit Postgres und Traefik

services:
  litellm:
    image: docker.litellm.ai/berriai/litellm:v1.105.0
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      LITELLM_MASTER_KEY: ${LITELLM_MASTER_KEY:?set in .env}
      LITELLM_SALT_KEY: ${LITELLM_SALT_KEY:?set in .env}
      DATABASE_URL: postgresql://litellm:${POSTGRES_PASSWORD}@db:5432/litellm
      STORE_MODEL_IN_DB: "True"
    labels:
      - traefik.enable=true
      - traefik.http.routers.litellm.rule=Host(`litellm.domain.com`)
      - traefik.http.routers.litellm.entrypoints=https
      - traefik.http.services.litellm.loadbalancer.server.port=4000
    networks:
      - traefik-net
  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: litellm
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 10
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - traefik-net
volumes:
  postgres_data:
networks:
  traefik-net:
    external: true

Die wichtigen Details:

• depends_on: condition: service_healthy mit einem pg_isready-Healthcheck. Schlichtes depends_on raced: LiteLLM kann starten, bevor Postgres Verbindungen annimmt, und landet dann im Crash-Loop. Dieses Muster fixt das.
• Die ${VAR:?set in .env}-Guards. Fehlendes LITELLM_MASTER_KEY oder LITELLM_SALT_KEY stoppt Compose, bevor irgendetwas startet.
• Traefik-Labels routen litellm.domain.com auf Port 4000 über den https-Entrypoint. Bring dein eigenes traefik-net mit. Siehe Traefik in Docker und das Wildcard-Zertifikat-Setup.
• postgres:16 mit einem Named Volume. Der offizielle Quickstart nutzt Named Volumes, und ich stimme für die meisten Leute zu.

    volumes:
      - postgres_data:/var/lib/postgresql/data
volumes:
  postgres_data:

    volumes:
      - ./litellm-db:/var/lib/postgresql/data:rw

docker compose up -d
docker compose ps

Erwartet: db meldet healthy und litellm meldet running. Wenn litellm neu startet, sind der DB-Healthcheck oder das DATABASE_URL-Passwort die üblichen Verdächtigen. Prüfe docker compose logs litellm.

Die Installation verifizieren und einen Test-Request schicken

Vertraue nicht darauf, dass docker compose up -d mit 0 zurückkommt. Vier Checks, in Reihenfolge.

# 1. container state
docker compose ps

# 2. liveness (from the host, or inside the container if 4000 is localhost-only)
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:4000/health/liveliness

# 3. first real call through the gateway
curl http://localhost:4000/v1/chat/completions \
  -H 'Authorization: Bearer sk-REPLACE_WITH_MASTER_OR_VIRTUAL_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gpt-5.6-terra",
    "messages": [{"role": "user", "content": "ping"}]
  }'

Wie „funktioniert” aussieht: eine JSON-Antwort mit choices[0].message.content und einem usage-Block. Wie „kaputt” aussieht: 401 heißt, der Bearer-Key ist falsch oder ihm fehlt der sk--Präfix; 400 mit model-not-found heißt, das "model"-Feld passt zu keinem model_name in deiner Config; 500 mit Provider-Fehlern heißt, der Upstream-Key ist ungültig oder der Modell-String ist für deinen Account nicht verfügbar.

Die Health-Endpoint-Namen sind langjährige LiteLLM-Routen, aber falls /health/liveliness auf deiner gepinnten Version einen 404 liefert, prüfe das OpenAPI-Schema dieser Version, bevor du annimmst, der Proxy sei tot.

LiteLLM Virtual Keys in der Admin-UI erstellen

Das ist das Feature, das den Postgres-Betrieb rechtfertigt. In der UI: Virtual Keys → Create New Key. Der Key wird genau einmal bei der Erstellung angezeigt.

Konfiguriere jeden Key mit:

Goldene Regel: Apps und Agents bekommen Virtual Keys, niemals den Master Key. Der Master Key kann deine Gateway-Config umschreiben; ein Virtual Key kann nur Modelle innerhalb seiner Limits aufrufen. Wenn du mehrere KI-Coding-Tools und Agents betreibst, gib jedem seinen eigenen Virtual Key, damit ein außer Kontrolle geratener Agent sein eigenes Budget frisst und nicht deins. Tools wie Agent Router können mehrere Coding-CLIs auf denselben Gateway-Endpoint richten.

Selbst mit Budgets pro Key: Setze Spend-Caps upstream beim Provider. Zwei Limits sind ein Limit, und das des Providers ist das, das deine Karte belastet.

Troubleshooting: Häufige Fehlerfälle

Wenn sich der Proxy unter Last komisch verhält, beobachte CPU und RAM, bevor du LiteLLM die Schuld gibst: How To Monitor Server and Docker Resources.

Backup, Upgrade und Rollback

Für Backups (DB-Modus):

docker compose exec db pg_dump -U litellm litellm > backup-$(date +%F).sql
# pair every dump with a copy of .env (the salt key decrypts stored provider keys)
cp .env .env.backup-$(date +%F)

Zum Upgraden:

1. Lies die Release Notes für die Minor-Linien, die du überspringst. Releases kommen wöchentlich, also ist „mehrere Minors springen” normal und die Notes sind kurz.
2. Mache zuerst einen frischen Dump. Seit v1.103.3 (30. September 2026) ist der DB-Migrations-Check standardmäßig erzwungen: Upgrades schlagen bei Schema-Drift hart fehl statt zu warnen. Das ist gut – solange du den Dump hast.
3. Erhöhe den Image-Tag in Compose, dann docker compose up -d.
4. Wiederhole die Verifizierungsschritte: /health/liveliness und ein echter /v1/chat/completions-Call.

Zum Zurückrollen setze den vorherigen gepinnten Tag in der Compose-Datei und docker compose up -d. Wenn Migrationen schon gelaufen sind und die alte Version am neuen Schema hängt, spiele zuerst den Dump in Postgres ein. Alte v1.83.x-stable-Tagnamen lösen weiterhin auf, falls du sie je brauchst; nackte und v-präfixierte Tags sind identische Images.

Hardening-Rekap:

• Halte Port 4000 auf 127.0.0.1 gebunden und lass Traefik den öffentlichen Traffic besitzen.
• Secrets nur in .env, chmod 600, niemals in Git.
• Nutze Virtual Keys für Clients; reserviere den Master Key für Admin-Arbeit.
• Ziehe litellm-non_root in Betracht, wenn deine Policy Non-Root-Container verlangt.

Was ist neu in LiteLLM seit Mai 2026

Das Projekt ist nicht stehen geblieben. Kurzliste, Details im Changelog:

Wenn du Traces und Spend-Dashboards über die eingebaute UI hinaus willst, kombiniere das Gateway mit self-hosted Langfuse für LLM-Observability. Das Gateway macht das Routing, Langfuse macht das „warum hat dieser Request $4 gekostet”-Gespräch.

Fazit

Der Betreiberpfad in einer Zeile: Image pinnen und verifizieren, mit der No-DB-Compose evaluieren, dann zu Postgres mit Salt Key und Virtual Keys für alles Ernsthafte wechseln. Verifiziere mit einem echten /v1/chat/completions-Call statt einem grünen docker compose ps zu vertrauen, und sichere den Datenbank-Dump zusammen mit dem Salt Key – sonst hast du nichts gesichert.

LiteLLM verdient seinen Platz im Stack, indem es Provider-Keys pro App und Retry-Logik pro App entfernt. Es ist nicht glamourös, es ist ein kleiner Container und eine YAML-Datei, die deine Modellausgaben und Credentials an einem langweiligen Ort halten.

Für alle, die mehr Docker-Container für ihr Self-Hosted-Setup erkunden wollen: Die besten 125+ Docker-Container für den Home Server in 2026 haben die aktuelle Liste. LiteLLM steht neben OmniRoute, Langfuse und dem Rest des Agent-Stacks in Top-KI-GitHub-Repos.