Wer in einem Team mehrere KI-Provider nutzt – heute OpenAI, morgen Anthropic, übermorgen ein lokales Ollama-Modell – steht schnell vor einem Verwaltungschaos: eigene API-Keys für jede Applikation, kein zentrales Budget-Tracking, keine Kontrolle darüber, welche Abteilung wie viel ausgibt. LiteLLM Proxy löst genau dieses Problem. Das Open-Source-Projekt mit über 40.000 GitHub-Stars stellt eine einheitliche, vollständig OpenAI-kompatible REST-API vor alle LLM-Provider, sodass bestehende SDKs und Tools ohne Codeänderung weiterlaufen. Dazu kommen Virtual Keys, Team-Budgets und automatisches Kosten-Tracking – alles über eine übersichtliche Admin-UI. Diese Anleitung zeigt dir, wie du LiteLLM mit Docker Compose, PostgreSQL-Backend und Admin-UI auf einem beliebigen Linux-Host produktionsreif aufsetzt.

Voraussetzungen

Docker Engine >= 24.x und Docker Compose Plugin >= 2.x auf einem Linux-Host, einer VM oder einem NAS mit Docker-Unterstützung – falls noch nicht installiert, lies zunächst Docker und Docker Compose auf Linux installieren (Ubuntu/Debian).
Mindestens 4 CPU-Kerne und 8 GB RAM (offizielle Mindestempfehlung); plus ca. 2 GB freier Speicherplatz für Images und Datenbankdaten.
API-Key eines LLM-Providers, zum Beispiel OpenAI (sk-...) oder Anthropic (sk-ant-...).
Internetzugang zum Ziehen der Docker-Images und zum Erreichen der Provider-APIs.
Optional: ein Reverse Proxy (z. B. Traefik oder Nginx Proxy Manager) für HTTPS-Terminierung, wenn LiteLLM öffentlich erreichbar sein soll.
Ein Passwort-Generator – openssl rand -hex 32 auf der Kommandozeile liefert sichere Zufallsstrings für LITELLM_MASTER_KEY und LITELLM_SALT_KEY.

Schritt 1: Projektordner anlegen

Erstelle einen dedizierten Ordner für alle LiteLLM-Dateien. In dieser Anleitung nutzen wir /opt/litellm; du kannst genauso gut ~/litellm wählen.

mkdir -p /opt/litellm
cd /opt/litellm

Alle folgenden Dateien – compose.yaml, .env und litellm_config.yaml – liegen in diesem Ordner.

Verifizieren: ls /opt/litellm zeigt den leeren Ordner; pwd gibt /opt/litellm zurück. Damit ist sichergestellt, dass spätere Volume-Mounts auf den richtigen Pfad zeigen.

Schritt 2: Secrets und Umgebungsvariablen in .env

Die .env-Datei enthält alle sensitiven Werte. Sie wird von Docker Compose automatisch eingelesen und darf nie in ein Git-Repository eingecheckt werden. Generiere zunächst zwei starke Zufallsstrings:

openssl rand -hex 32   # für LITELLM_MASTER_KEY (mit sk- präfixen!)
openssl rand -hex 32   # für LITELLM_SALT_KEY

Lege danach die Datei /opt/litellm/.env an:

# LiteLLM Master Key – MUSS mit sk- beginnen
LITELLM_MASTER_KEY=sk-dein-generierter-zufallsstring-hier

# Salt Key – verschlüsselt alle in der DB gespeicherten Provider-Keys
# WARNUNG: Diesen Wert NIEMALS nach dem ersten Start ändern!
LITELLM_SALT_KEY=dein-zweiter-zufallsstring-hier

# Admin-UI Zugangsdaten
UI_USERNAME=admin
UI_PASSWORD=einSicheresPasswort123!

# PostgreSQL-Zugangsdaten
POSTGRES_USER=llmproxy
POSTGRES_PASSWORD=dbSicheresPasswort456!
POSTGRES_DB=litellm

# LLM-Provider-Keys (nur ausfüllen, was du tatsächlich nutzt)
OPENAI_API_KEY=sk-proj-dein-openai-key
ANTHROPIC_API_KEY=sk-ant-dein-anthropic-key

Wichtige Hinweise zu den Werten:

LITELLM_MASTER_KEY muss exakt mit sk- beginnen – sonst schlägt die Key-Generierung und die UI-Authentifizierung fehl.
LITELLM_SALT_KEY verschlüsselt alle in der Datenbank gespeicherten Provider-Credentials. Wenn du diesen Wert nach dem ersten Start änderst, werden alle gespeicherten Keys unlesbar.
UI_PASSWORD muss gesetzt werden – ohne Passwort ist die Admin-UI für jeden im Netzwerk ohne Authentifizierung erreichbar.

Verifizieren: cat /opt/litellm/.env zeigt alle Variablen korrekt. Stelle sicher, dass LITELLM_MASTER_KEY mit sk- beginnt und beide Zufallsstrings ausgefüllt sind.

Schritt 3: Modell-Konfiguration in litellm_config.yaml

Die litellm_config.yaml definiert, welche Modelle der Proxy anbietet. Provider-Keys werden dabei sicher via os.environ/VARIABLENNAME referenziert – niemals als Klartext. Das folgende Beispiel bindet OpenAI GPT-4o und Anthropic Claude 3.5 Sonnet ein:

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

  - model_name: claude-3-5-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: os.environ/ANTHROPIC_API_KEY

  # Lokales Ollama-Modell (kein API-Key nötig)
  # - model_name: llama3
  #   litellm_params:
  #     model: ollama/llama3
  #     api_base: http://host.docker.internal:11434

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Wenn du STORE_MODEL_IN_DB=True setzt (wie in der compose.yaml weiter unten), kannst du Modelle alternativ auch direkt über die Admin-UI hinzufügen, ohne die YAML-Datei anzupassen und den Container neu zu starten. Für den ersten Start muss die Datei jedoch existieren und korrekt gemountet sein – ein fehlender Mount führt zu einem Config not found-Fehler.

Verifizieren: cat /opt/litellm/litellm_config.yaml zeigt die Konfiguration. Die Einrückung muss korrekt sein (2 Leerzeichen); YAML ist einrückungsempfindlich.

Schritt 4: Docker-Compose-Stack definieren

Die compose.yaml definiert zwei Services: den LiteLLM-Proxy selbst und eine PostgreSQL-16-Datenbank. Der LiteLLM-Container wartet mit depends_on condition: service_healthy darauf, dass die Datenbank bereit ist, bevor er startet.

Eckdaten auf einen Blick

Eigenschaft	Wert	Hinweis
Image (stabil, amd64)	`docker.litellm.ai/berriai/litellm:main-stable`	Offizielle primäre Registry
Image (ARM64)	`ghcr.io/berriai/litellm:v1.88.1`	Pflicht für Raspberry Pi und Apple Silicon
Port	4000:4000	API + Admin-UI (`/ui`, `/health`)
Config-Volume	`./litellm_config.yaml:/app/config.yaml`	Pflicht; muss vor Start existieren
DB-Volume	`litellm_postgres_data` (benannt)	PostgreSQL-Datenpersistenz
Mindest-Hardware	4 CPU-Kerne, 8 GB RAM	Offizielle Mindestempfehlung

Lege jetzt /opt/litellm/compose.yaml an:

services:
  litellm:
    image: docker.litellm.ai/berriai/litellm:main-stable
    # ARM64-Hosts (Raspberry Pi, Apple Silicon) stattdessen:
    # image: ghcr.io/berriai/litellm:v1.88.1
    container_name: litellm
    restart: unless-stopped
    ports:
      - "4000:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml"]
    env_file:
      - .env
    environment:
      DATABASE_URL: "postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@db:5432/${POSTGRES_DB}"
      LITELLM_MASTER_KEY: "${LITELLM_MASTER_KEY}"
      LITELLM_SALT_KEY: "${LITELLM_SALT_KEY}"
      STORE_MODEL_IN_DB: "True"
      UI_USERNAME: "${UI_USERNAME}"
      UI_PASSWORD: "${UI_PASSWORD}"
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:4000/health/liveliness"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 60s

  db:
    image: postgres:16
    container_name: litellm-postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: "${POSTGRES_USER}"
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
      POSTGRES_DB: "${POSTGRES_DB}"
    volumes:
      - litellm_postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -d ${POSTGRES_DB} -U ${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s

volumes:
  litellm_postgres_data:
    driver: local

Ein Hinweis zur start_period: LiteLLM führt beim allerersten Start Prisma-Datenbankmigrationen durch. Das dauert auf normaler Hardware 30–90 Sekunden. Die 60 Sekunden start_period im Healthcheck verhindern, dass Docker Compose den Container vorschnell als ungesund markiert. Auf langsamer Hardware empfiehlt sich 120s.

Verifizieren: Alle drei Dateien müssen im Ordner liegen:

ls -la /opt/litellm/
# Erwartete Ausgabe:
# .env
# compose.yaml
# litellm_config.yaml

Schritt 5: Stack starten

Starte jetzt alle Services im Hintergrund:

cd /opt/litellm
docker compose up -d

Docker lädt beim ersten Start die Images herunter (ca. 1,5–2 GB), erstellt das benannte Volume und startet PostgreSQL. LiteLLM wartet automatisch, bis die Datenbank den Healthcheck besteht, und führt dann die Prisma-Migrationen durch.

Verfolge den Start in Echtzeit:

docker compose logs -f litellm

Typische Ausgabe nach erfolgreichem Start:

litellm  | INFO:     Application startup complete.
litellm  | INFO:     Uvicorn running on http://0.0.0.0:4000 (Press CTRL+C to quit)

Verifizieren: Prüfe den Status beider Container:

docker compose ps
# NAME               IMAGE                                          STATUS
# litellm            docker.litellm.ai/berriai/litellm:main-stable  Up (healthy)
# litellm-postgres   postgres:16                                    Up (healthy)

Beide Container müssen den Status Up (healthy) zeigen. Ist LiteLLM noch im Zustand starting, warte weitere 60–90 Sekunden und prüfe erneut. Dann teste den Liveness-Endpunkt:

curl -s http://localhost:4000/health/liveliness
# Erwartete Ausgabe: {"status": "healthy"}

Schritt 6: Admin-UI und erste API-Tests

Öffne im Browser http://localhost:4000/ui (bzw. die IP deines Hosts). Das Login-Formular erwartet die Zugangsdaten aus UI_USERNAME und UI_PASSWORD aus deiner .env.

In der Admin-UI kannst du:

Virtual Keys generieren – individuelle API-Keys für Nutzer, Teams oder Applikationen mit eigenen Budget-Limits
Modelle verwalten – neue Provider hinzufügen ohne Container-Neustart (dank STORE_MODEL_IN_DB=True)
Usage & Spend einsehen – Kosten pro Key, User und Team in USD, automatisch aus den offiziellen Provider-Preislisten berechnet
Rate Limits setzen – maximale Requests pro Minute oder Token-Budgets pro Zeitraum

Teste die API direkt mit curl – ersetze sk-dein-master-key durch deinen LITELLM_MASTER_KEY:

curl -s http://localhost:4000/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-dein-master-key" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Sag kurz Hallo auf Deutsch."}]
  }' | python3 -m json.tool

Bestehende OpenAI-SDK-Integrationen stellst du auf LiteLLM um, indem du nur zwei Parameter änderst:

# Python-Beispiel
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:4000",   # LiteLLM statt api.openai.com
    api_key="sk-dein-master-key",       # dein LITELLM_MASTER_KEY
)
# Keine weiteren Code-Änderungen nötig!

Verifizieren: Der curl-Test gibt eine JSON-Antwort mit "role": "assistant" zurück. Im Browser lädt die Admin-UI unter http://localhost:4000/ui das Dashboard nach dem Login. Die Logs zeigen den eingehenden Request:

docker compose logs --tail=20 litellm
# INFO: POST /chat/completions HTTP/1.1" 200 OK

Schritt 7: Wartung – Updates und Backup

LiteLLM erscheint wöchentlich in neuen Versionen. Ein Update auf das neueste main-stable-Image ist mit zwei Befehlen erledigt:

cd /opt/litellm
docker compose pull
docker compose up -d

Docker Compose lädt das neue Image und startet den Container neu. Die PostgreSQL-Daten bleiben im benannten Volume litellm_postgres_data erhalten.

Für ein Backup der Datenbank nutze pg_dump über den laufenden Container:

docker exec litellm-postgres pg_dump \
  -U llmproxy litellm > /opt/litellm/backup_$(date +%Y%m%d).sql

Speichere außerdem regelmäßig die .env und litellm_config.yaml an einem sicheren Ort. Ohne den LITELLM_SALT_KEY aus der .env sind alle in der DB gespeicherten Provider-Keys nach einem Datenverlust unlesbar. Ein vollständiges Backup-Konzept für PostgreSQL-Daten beschreibt die Anleitung MySQL & PostgreSQL Backup automatisieren mit cron.

Verifizieren: Nach dem Update zeigt docker compose ps wieder Up (healthy). Die Versionsnummer des neuen Images ist in docker compose images sichtbar. Das Backup-SQL liegt unter /opt/litellm/backup_YYYYMMDD.sql.

Troubleshooting / Typische Fehler

Error decrypting value – Did your master_key/salt key change recently?
Der LITELLM_SALT_KEY wurde nach dem ersten Start geändert. Alle in der DB verschlüsselten Provider-Keys sind damit unlesbar. Lösung: docker compose down -v (löscht auch das Volume!), dann LITELLM_SALT_KEY auf den ursprünglichen Wert zurücksetzen und mit docker compose up -d neu starten.
401 Unauthorized bei /key/generate
Der LITELLM_MASTER_KEY beginnt nicht mit sk-. In der .env korrigieren, Container mit docker compose up -d neu starten.
Config not found beim Start
Die Datei litellm_config.yaml existiert nicht oder ist nicht korrekt als Volume eingebunden. Prüfe, ob die Datei unter /opt/litellm/litellm_config.yaml liegt und der Volume-Pfad im compose.yaml mit ./litellm_config.yaml:/app/config.yaml übereinstimmt.
exec format error beim Container-Start
Docker Hub-Image auf einem ARM64-Host (Raspberry Pi, Apple Silicon). Lösung: Image auf ghcr.io/berriai/litellm:v1.88.1 umstellen – Docker Hub hat kein ARM64-Manifest für LiteLLM.
LiteLLM startet, bevor PostgreSQL bereit ist (Connection refused, Prisma-Fehler)
Der depends_on condition: service_healthy-Block fehlt oder start_period ist zu kurz. Auf langsamer Hardware start_period: 120s setzen, dann docker compose down && docker compose up -d.
Admin-UI ohne Passwortschutz erreichbar
UI_PASSWORD ist nicht in der .env gesetzt. Sofort nachholen und docker compose up -d ausführen.
Alle Services starten nicht, obwohl compose.yaml Prometheus enthält
Die Datei prometheus.yml fehlt. Entweder die Datei anlegen oder den Prometheus-Service in der compose.yaml auskommentieren.
Veraltete Daten nach Neukonfiguration
Bei Problemen nach einer Neukonfiguration immer zuerst docker compose down -v ausführen, um auch das Volume zu löschen.

Häufige Fragen

Kann ich LiteLLM ohne PostgreSQL betreiben?

Ja. Für einfache Proxy-Nutzung ohne Key-Management reicht ein minimales Setup ohne DATABASE_URL, LITELLM_SALT_KEY und den db-Service. Die Admin-UI und Virtual Keys sind dann jedoch nicht verfügbar. Für Homelab-Tests ohne Team-Anforderungen ist das vollkommen ausreichend.

Wie füge ich einen neuen LLM-Provider hinzu?

Zwei Wege: Entweder trägst du in litellm_config.yaml einen neuen Eintrag unter model_list ein und startest den Container neu. Oder – wenn STORE_MODEL_IN_DB=True gesetzt ist – navigierst du im Admin-UI zu „Models" und fügst das Modell direkt über die Oberfläche hinzu, ohne Container-Neustart.

Wie stelle ich bestehende OpenAI-SDK-Integrationen um?

Nur zwei Parameter müssen geändert werden: base_url auf http://localhost:4000 und api_key auf deinen LITELLM_MASTER_KEY. Kein weiterer Code ändert sich – alle OpenAI-API-Pfade sind vollständig kompatibel.

Wo sehe ich die tatsächlichen Kosten pro API-Aufruf?

Im Admin-UI unter http://localhost:4000/ui im Bereich „Usage" findest du eine Aufschlüsselung nach Key, User und Team. Per API erreichst du dieselben Daten mit GET /spend und deinem Master Key als Bearer Token. Kosten werden automatisch anhand der offiziellen Provider-Preislisten in USD berechnet.

Was kostet LiteLLM in der Open-Source-Version?

Nichts. Die Open-Source-Version hat keine Limits auf Users, Keys oder Teams. Enterprise-Features wie SSO und Audit Logs sind kostenpflichtig. Für die meisten KMU-Setups reicht die Open-Source-Version vollständig aus.

Wann brauche ich Redis?

Bei mehr als 1.000 Requests pro Sekunde empfiehlt die offizielle Dokumentation Redis, um Datenbankdeadlocks zu vermeiden. Für die überwiegende Mehrheit der KMU-Setups ist Redis nicht erforderlich und lässt sich später als weiterer Service ergänzen.

Sind die Docker-Images vertrauenswürdig?

Alle LiteLLM-Docker-Images sind mit cosign signiert und können kryptographisch verifiziert werden. Das Projekt ist aktiv gepflegt (über 40.000 GitHub-Stars, wöchentliche Releases, aktuell v1.88.1).

Fazit

LiteLLM Proxy ist eine der elegantesten Lösungen für das zentrale Management von KI-Provider-Zugriffen in Teams. Der einmalige Aufwand von 25 Minuten für das Docker-Compose-Setup zahlt sich schnell aus: Kein Entwickler braucht mehr eigene Provider-Keys, Budgets sind pro Team oder Projekt kontrollierbar, und der Wechsel zwischen OpenAI, Anthropic oder einem lokalen Ollama-Modell ist eine Konfigurationszeile. Der wichtigste Fallstrick – der LITELLM_SALT_KEY darf sich nach dem ersten Start nie ändern – ist leicht zu vermeiden, wenn man ihn von Anfang an sicher aufbewahrt. Für Teams, die heute mit einem Provider starten und morgen flexibel wechseln wollen, ist LiteLLM die Infrastruktur-Grundlage schlechthin.

Wer LiteLLM mit einem lokalen Sprachmodell kombinieren möchte, findet in der Anleitung Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud betreiben den passenden Einstieg. Für komplexere KI-Workflows, bei denen LiteLLM als API-Schicht dient, lohnt sich ein Blick auf n8n mit Docker: KI-Workflows und Automatisierung self-hosted.

Weiterführende Anleitungen und Quellen

Offizielle Quellen: LiteLLM Proxy Deployment Dokumentation · LiteLLM GitHub-Repository (BerriAI/litellm) · Virtual Keys & Cost Tracking · Config.yaml Struktur