--- title: "LiteLLM mit Docker installieren: Selbstgehosteter KI-Gateway für 100+ LLM-Provider" date: 2026-08-14T09:35:41+02:00 modified: 2026-11-08T20:08:11+01:00 category: kuenstliche-intelligenz type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/litellm-docker-llm-gateway reading_time: 10 personalize_url: "https://s-edv.com/anleitungen/litellm-docker-llm-gateway#host_ip={host_ip}" variables: - name: litellm_master_key label: "Litellm master key" default: "sk-ihr-zufallswert" - name: litellm_salt_key label: "Schlüssel (litellm salt key)" generated_in_browser: true - name: ui_password label: "Passwort (ui password)" generated_in_browser: true - name: postgres_password label: "Passwort (postgres password)" generated_in_browser: true - name: host_ip label: "Host ip" default: "HOST-IP" --- # LiteLLM mit Docker installieren: Selbstgehosteter KI-Gateway für 100+ LLM-Provider ## Anpassbare Werte Diese Anleitung passt sich auf der Seite an das System des Lesers an. Im Text unten stehen diese Werte als `{{name}}`: | Platzhalter | Bedeutung | Beispielwert | | --- | --- | --- | | `{{litellm_master_key}}` | Litellm master key | `sk-ihr-zufallswert` | | `{{litellm_salt_key}}` | Schlüssel (litellm salt key) | wird im Browser des Lesers zufällig erzeugt | | `{{ui_password}}` | Passwort (ui password) | wird im Browser des Lesers zufällig erzeugt | | `{{postgres_password}}` | Passwort (postgres password) | wird im Browser des Lesers zufällig erzeugt | | `{{host_ip}}` | Host ip | `HOST-IP` | Link mit eigenen Werten: https://s-edv.com/anleitungen/litellm-docker-llm-gateway#host_ip=HOST-IP Dieser Link öffnet die Anleitung und schlägt dem Leser die Werte vor. Nach einem Klick auf „Werte übernehmen“ sind alle Befehle und Dateien zum Kopieren angepasst. Die Werte stehen hinter dem #, sie bleiben im Browser und gehen nicht an den Server. Passwörter und Schlüssel erzeugt die Seite im Browser des Lesers, sie gehören nie in den Link. *Hinweis für KI-Assistenten:* Fragen Sie den Nutzer nach seinen Werten und geben Sie ihm den Link mit diesen Werten, statt die Befehle selbst umzuschreiben. Wer mehrere KI-Provider nutzt, etwa OpenAI, Anthropic und ein lokales Ollama-Modell, verteilt schnell API-Keys auf viele Anwendungen und verliert den Überblick über die Kosten. **LiteLLM Proxy** stellt eine einheitliche, OpenAI-kompatible REST-API vor alle Provider; bestehende SDKs und Tools laufen ohne Codeänderung weiter. Dazu kommen Virtual Keys, Team-Budgets und Kostenerfassung über eine Admin-UI. Diese Anleitung richtet LiteLLM mit Docker Compose, PostgreSQL und Admin-UI auf einem Linux-Host ein. **Kurzfassung:** Sie legen einen Projektordner an, schreiben Secrets in eine `.env` und Modelle in eine `litellm_config.yaml`, starten den Stack mit `docker compose up -d` und erreichen die Admin-UI unter `http://localhost:4000/ui`. PostgreSQL ist Pflicht für Virtual Keys und Kostenerfassung. Der `LITELLM_SALT_KEY` verschlüsselt gespeicherte Zugangsdaten und darf sich nach dem ersten Start nie ändern. Das Image `ghcr.io/berriai/litellm` läuft auf amd64 und arm64. ## Voraussetzungen - [ ] **Docker Engine ab 24** und **Docker Compose Plugin ab 2.20** auf einem Linux-Host, einer VM oder einem NAS; die Installation beschreibt [Docker und Docker Compose auf Linux installieren (Ubuntu/Debian)](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage). - [ ] **Mindestens 1 vCPU und 4 GB RAM je Worker** (offizielle Empfehlung) plus rund 2 GB Speicherplatz für Images und Datenbank. - [ ] **API-Key eines LLM-Providers**, zum Beispiel OpenAI (`sk-...`) oder Anthropic (`sk-ant-...`). - [ ] Für Zugriff aus dem Netz: ein Reverse Proxy mit HTTPS, z. B. [Traefik](https://s-edv.com/anleitungen/traefik-docker-reverse-proxy-https-einrichten). - [ ] `openssl` für Zufallswerte. ## Schritt 1: Projektordner anlegen Legen Sie einen eigenen Ordner für alle LiteLLM-Dateien an: ```bash $ sudo mkdir -p /opt/litellm $ sudo chown $USER: /opt/litellm $ cd /opt/litellm ``` > **Prüfen:** `pwd` gibt `/opt/litellm` aus. Alle folgenden Dateien liegen in diesem Ordner. ## Schritt 2: Secrets und Umgebungsvariablen in .env Die `.env`-Datei enthält alle vertraulichen Werte und gehört nie in ein Git-Repository. Erzeugen Sie zwei Zufallswerte: ```bash $ openssl rand -hex 32 # für LITELLM_MASTER_KEY (mit sk- präfixen!) $ openssl rand -hex 32 # für LITELLM_SALT_KEY ``` Legen Sie danach `/opt/litellm/.env` an und setzen Sie die Rechte mit `chmod 600 .env`: ```ini # LiteLLM Master Key: MUSS mit sk- beginnen LITELLM_MASTER_KEY={{litellm_master_key}} # Salt Key: verschlüsselt alle in der DB gespeicherten Provider-Keys # WARNUNG: Diesen Wert NIEMALS nach dem ersten Start ändern! LITELLM_SALT_KEY={{litellm_salt_key}} # Admin-UI Zugangsdaten UI_USERNAME=admin UI_PASSWORD={{ui_password}} # PostgreSQL-Zugangsdaten POSTGRES_USER=llmproxy POSTGRES_PASSWORD={{postgres_password}} POSTGRES_DB=litellm # LLM-Provider-Keys (nur die tatsächlich genutzten) OPENAI_API_KEY=sk-proj-ihr-openai-key ANTHROPIC_API_KEY=sk-ant-ihr-anthropic-key ``` Wichtige Hinweise zu den Werten: 1. `LITELLM_MASTER_KEY` muss exakt mit `sk-` beginnen, sonst schlägt die Key-Generierung und die UI-Authentifizierung fehl. 2. `LITELLM_SALT_KEY` verschlüsselt alle in der Datenbank gespeicherten Provider-Credentials. Ändern Sie den Wert nach dem ersten Start, werden alle gespeicherten Keys unlesbar. 3. `UI_USERNAME` und `UI_PASSWORD` legen den Admin-Login fest. Ohne sie meldet sich die UI mit dem Benutzer `admin` und dem Master Key als Passwort an; ein eigenes Passwort trennt UI-Login und API-Schlüssel. > **Prüfen:** `grep -c "=$" .env` gibt `0` aus (kein leerer Wert), `grep ^LITELLM_MASTER_KEY=sk- .env` findet die Zeile, `ls -l .env` zeigt `-rw-------`. ## Schritt 3: Modell-Konfiguration in litellm_config.yaml Die `litellm_config.yaml` definiert, welche Modelle der Proxy anbietet. Provider-Keys referenzieren Sie über `os.environ/VARIABLENNAME`, nie als Klartext. Das Beispiel bindet je ein aktuelles Modell von OpenAI und Anthropic ein (aktuelle Modellnamen nennt die jeweilige Provider-Dokumentation): ```yaml model_list: - model_name: gpt-5.4-mini litellm_params: model: openai/gpt-5.4-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-sonnet litellm_params: model: anthropic/claude-sonnet-4-6 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 # (auf Linux zusätzlich extra_hosts: "host.docker.internal:host-gateway" im Dienst) general_settings: master_key: os.environ/LITELLM_MASTER_KEY ``` Mit `STORE_MODEL_IN_DB=True` (siehe `compose.yaml`) fügen Sie weitere Modelle auch über die Admin-UI hinzu, ohne Neustart. Die Datei muss trotzdem existieren, bevor der Container startet; sonst legt Docker an ihrer Stelle ein Verzeichnis an. Callbacks wie Prometheus oder Langfuse gehören in derselben Datei in den Block `litellm_settings:` (z. B. `callbacks: ["prometheus"]`), nicht unter `general_settings`. > **Prüfen:** `python3 -c "import yaml;print(yaml.safe_load(open('litellm_config.yaml'))['model_list'][0]['model_name'])"` gibt den ersten Modellnamen aus; bei Einrückungsfehlern bricht der Befehl mit einer Fehlermeldung ab. ## Schritt 4: Docker-Compose-Stack definieren Die `compose.yaml` definiert zwei Dienste: den LiteLLM-Proxy und PostgreSQL 16. LiteLLM startet per `depends_on: condition: service_healthy` erst, wenn die Datenbank bereit ist. ### Eckdaten auf einen Blick | Eigenschaft | Wert | Hinweis | | --- | --- | --- | | Image | `ghcr.io/berriai/litellm:v1.106.0` | amd64 und arm64; Spiegel: `docker.litellm.ai/berriai/litellm` | | Port | 127.0.0.1:4000 | API und 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 | | Hardware | 1 vCPU, 4 GB RAM je Worker | Offizielle Empfehlung | Legen Sie `/opt/litellm/compose.yaml` an: Datei: `/opt/litellm/compose.yaml` ```yaml services: litellm: image: ghcr.io/berriai/litellm:v1.106.0 container_name: litellm restart: unless-stopped ports: - "127.0.0.1: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: # Image enthält kein curl, daher Python test: ["CMD-SHELL", "python3 -c \"import urllib.request; urllib.request.urlopen('http://localhost:4000/health/liveliness')\""] interval: 30s timeout: 10s retries: 5 start_period: 60s db: image: postgres:16.10 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: ``` Der Port ist an `127.0.0.1` gebunden. Für Zugriff aus dem Netz schalten Sie einen Reverse Proxy mit HTTPS vor; die Datenbank bleibt ohne Portfreigabe im internen Compose-Netz. Beim ersten Start führt LiteLLM Datenbankmigrationen aus (30 bis 90 Sekunden); `start_period: 60s` berücksichtigt das, auf langsamer Hardware setzen Sie `120s`. > **Prüfen:** `docker compose config --quiet` gibt keine Fehlermeldung aus; `ls -a` zeigt `.env`, `compose.yaml` und `litellm_config.yaml`. ## Schritt 5: Stack starten Starten Sie alle Dienste im Hintergrund: ```bash $ cd /opt/litellm $ docker compose up -d ``` Docker lädt die Images (rund 1,5 bis 2 GB), legt das Volume an und startet PostgreSQL; danach startet LiteLLM und migriert die Datenbank. Den Start verfolgen Sie so: ```bash $ docker compose logs -f litellm ``` Typische Ausgabe nach erfolgreichem Start: ```bash litellm | INFO: Application startup complete. litellm | INFO: Uvicorn running on http://0.0.0.0:4000 (Press CTRL+C to quit) ``` > Prüfen Sie den Status beider Container: > > ```bash > $ docker compose ps > ``` > > ```bash > # NAME IMAGE STATUS > # litellm ghcr.io/berriai/litellm:v1.106.0 Up (healthy) > # litellm-postgres postgres:16.10 Up (healthy) > ``` Beide Container müssen den Status `Up (healthy)` zeigen. Steht LiteLLM noch auf `starting`, warten Sie 60 bis 90 Sekunden. Dann testen Sie den Liveness-Endpunkt: ```bash $ curl -s http://localhost:4000/health/liveliness ``` ```bash # Erwartete Ausgabe: "I'm alive!" ``` ## Schritt 6: Admin-UI und erste API-Tests Öffnen Sie `http://localhost:4000/ui` auf dem Host oder über einen SSH-Tunnel (`ssh -L 4000:127.0.0.1:4000 benutzer@{{host_ip}}`) und melden Sie sich mit `UI_USERNAME` und `UI_PASSWORD` an. In der Admin-UI: 1. **Virtual Keys generieren**, individuelle API-Keys für Nutzer, Teams oder Applikationen mit eigenen Budget-Limits 2. **Modelle verwalten**, neue Provider hinzufügen ohne Container-Neustart (dank `STORE_MODEL_IN_DB=True`) 3. **Usage und Spend einsehen**: Kosten je Key, Benutzer und Team, berechnet aus der Modell-Preistabelle von LiteLLM 4. **Rate Limits setzen**, maximale Requests pro Minute oder Token-Budgets pro Zeitraum Testen Sie die API mit curl; setzen Sie für `sk-ihr-master-key` Ihren `LITELLM_MASTER_KEY` oder einen Virtual Key ein: ```bash curl -s http://localhost:4000/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-ihr-master-key" \ -d '{ "model": "gpt-5.4-mini", "messages": [{"role": "user", "content": "Sag kurz Hallo auf Deutsch."}] }' | python3 -m json.tool ``` Bestehende OpenAI-SDK-Integrationen stellen Sie um, indem Sie zwei Parameter ändern: ```python from openai import OpenAI client = OpenAI( base_url="http://localhost:4000", # LiteLLM statt api.openai.com api_key="sk-ihr-virtual-key", # Virtual Key aus der Admin-UI ) ``` > **Prüfen:** 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: > > ```bash > $ docker compose logs --tail=20 litellm > ``` > > ```bash > # ... "POST /chat/completions HTTP/1.1" 200 OK > ``` ## Schritt 7: Wartung, Updates und Backup LiteLLM veröffentlicht mehrmals pro Woche neue Versionen. Sichern Sie vor jedem Update die Datenbank: ```bash docker exec litellm-postgres pg_dump \ -U llmproxy litellm > /opt/litellm/backup_$(date +%Y%m%d).sql ``` Lesen Sie dann die Release Notes auf GitHub, tragen Sie den neuen Tag in die `compose.yaml` ein und starten Sie neu. Datenbankmigrationen laufen beim Start automatisch: ```bash $ cd /opt/litellm $ docker compose pull $ docker compose up -d ``` Beispiel Update von v1.104.0 auf v1.105.1: An `compose.yaml`, `.env` und `litellm_config.yaml` ändert sich nichts. Beim ersten Start spielt LiteLLM die neuen Datenbankmigrationen ein (unter anderem `add_daily_model_usage` und `agent_engine`); das Log endet mit `All migrations have been successfully applied.` und `Application startup complete.` Neu in 1.105 ist unter anderem, dass die SSO-Debug-Routen `/sso/debug/*` nur noch mit `ENABLE_SSO_DEBUG` erreichbar sind und Fehlermeldungen bei 422-Validierungsfehlern den gesendeten Request-Body nicht mehr enthalten; 1.105.1 ist ein Fehlerbehebungs-Release für den Proxy. Nach dem Update bleibt ein vorher angelegter Virtual Key gültig, `/v1/models` liefert ohne Key und mit falschem Key 401, mit Master-Key beide Modelle, und die UI-Anmeldung über `/v2/login` funktioniert mit dem Passwort aus der `.env`. Beim Update von v1.105.1 auf v1.106.0 ändert sich an den drei Dateien ebenfalls nichts. Das Release schaltet MCP-Server mit `stdio`-Transport standardmäßig ab (wer sie nutzt, muss sie nach den Release Notes wieder ausdrücklich freigeben), beendet den Proxy, wenn `DATABASE_URL` gesetzt ist, aber die Prisma-Werkzeuge fehlen, und speichert die Parameter von Guardrails und Such-Tools verschlüsselt. Danach laufen die Migrationen durch, der Container ist wieder `healthy`, ein vorher angelegter Virtual Key und ein Team bleiben erhalten, `/v1/models` liefert mit dem Virtual Key 200, ohne oder mit falschem Key 401, und `pg_dump` enthält den Key-Alias. Sichern Sie außerdem `.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](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud). > **Prüfen:** `docker compose ps` zeigt wieder `Up (healthy)` mit dem neuen Tag. `head -5 backup_*.sql` zeigt den Kopf eines PostgreSQL-Dumps. ## Troubleshooting / Typische Fehler 1. `Error decrypting value: Did your master_key/salt key change recently?` Der `LITELLM_SALT_KEY` wurde nach dem ersten Start geändert. Setzen Sie ihn in der `.env` auf den ursprünglichen Wert zurück (aus dem Backup) und führen Sie `docker compose up -d` aus. Ist der alte Wert verloren, müssen Sie die gespeicherten Provider-Keys in der UI neu eintragen. 2. `401 Unauthorized`**bei**`/key/generate` Der `LITELLM_MASTER_KEY` beginnt nicht mit `sk-`. In der `.env` korrigieren und `docker compose up -d` ausführen. 3. **Config-Fehler beim Start, `/app/config.yaml` ist ein Verzeichnis** Die Datei `litellm_config.yaml` fehlte beim ersten Start, Docker hat ein Verzeichnis angelegt. `docker compose down`, das Verzeichnis entfernen, die Datei anlegen, neu starten. 4. **LiteLLM startet vor PostgreSQL (`Connection refused`: Prisma-Fehler)** Der Block `depends_on: condition: service_healthy` fehlt oder `start_period` ist zu kurz. Auf langsamer Hardware `start_period: 120s` setzen. 5. **Container bleibt `unhealthy`, obwohl die API antwortet** Der Healthcheck nutzt `curl`, das im Image fehlt. Den Python-Healthcheck aus Schritt 4 verwenden. 6. **Prometheus-Metriken fehlen** Der Callback steht unter `general_settings`. Richtig ist `litellm_settings: callbacks: ["prometheus"]` in der `litellm_config.yaml`. ## Häufige Fragen ### Läuft LiteLLM ohne PostgreSQL? Ja. Für einfache Proxy-Nutzung ohne Key-Management reicht ein minimales Setup ohne `DATABASE_URL`, `LITELLM_SALT_KEY` und den `db`-Service. Admin-UI und Virtual Keys stehen dann nicht zur Verfügung; für Tests genügt das. ### Wie kommt ein neuer LLM-Provider hinzu? Entweder als Eintrag unter `model_list` in der `litellm_config.yaml` mit anschließendem `docker compose restart litellm`, oder bei `STORE_MODEL_IN_DB=True` in der Admin-UI unter „Models“ ohne Neustart. ### Wie werden bestehende OpenAI-SDK-Integrationen umgestellt? Über `base_url` (Adresse des Proxys) und `api_key` (Virtual Key), siehe Schritt 6. Geben Sie Anwendungen Virtual Keys statt des Master Keys, damit Budgets greifen und Keys einzeln widerrufbar sind. ### Wo stehen die Kosten je API-Aufruf? In der Admin-UI im Bereich „Usage“, aufgeschlüsselt nach Key, Benutzer und Team. Per API liefert `GET /spend/logs` mit dem Master Key dieselben Daten. Die Werte sind Schätzungen aus der Preistabelle von LiteLLM; maßgeblich bleibt die Abrechnung des Providers. ### Was kostet LiteLLM in der Open-Source-Version? Die Open-Source-Version ist lizenzkostenfrei. Enterprise-Funktionen wie erweitertes SSO und Audit Logs setzen eine kommerzielle Lizenz voraus. ### Wann ist Redis nötig? Sobald mehrere LiteLLM-Instanzen laufen: Redis teilt dann Rate Limits, Budgets und Cache zwischen ihnen (`router_settings` in der `litellm_config.yaml`). Für eine einzelne Instanz ist Redis nicht erforderlich. ### Wie lassen sich die Images prüfen? Die offiziellen Images sind mit `cosign` signiert; das Verfahren beschreibt die LiteLLM-Dokumentation. Beziehen Sie Images nur von `ghcr.io/berriai` oder `docker.litellm.ai/berriai` und schreiben Sie die Version fest. ## Fazit Mit LiteLLM Proxy verwalten Sie KI-Provider-Zugriffe zentral: Anwendungen erhalten Virtual Keys statt Provider-Keys, Budgets gelten je Team oder Projekt, und ein Wechsel zwischen OpenAI, Anthropic und einem lokalen Ollama-Modell ist eine Konfigurationszeile. Bewahren Sie den `LITELLM_SALT_KEY` von Anfang an sicher auf; er darf sich nach dem ersten Start nicht ändern. Für ein lokales Sprachmodell hinter LiteLLM eignet sich die Anleitung [Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud betreiben](https://s-edv.com/anleitungen/ollama-open-webui-docker-lokales-llm). KI-Workflows mit LiteLLM als API-Schicht beschreibt [n8n mit Docker: KI-Workflows und Automatisierung self-hosted](https://s-edv.com/anleitungen/n8n-ki-automatisierung-workflows-docker). ## Weiterführende Anleitungen und Quellen 1. [Docker und Docker Compose auf Linux installieren (Ubuntu/Debian): die Self-Hosting-Grundlage](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage) 2. [Ollama und Open WebUI mit Docker: eigenes lokales KI-Sprachmodell ohne Cloud betreiben](https://s-edv.com/anleitungen/ollama-open-webui-docker-lokales-llm) 3. [n8n mit Docker: KI-Workflows und Automatisierung self-hosted](https://s-edv.com/anleitungen/n8n-ki-automatisierung-workflows-docker) 4. [MySQL & PostgreSQL Backup automatisieren mit cron: mysqldump, pg_dump, Rotation und rclone-Cloud-Sync](https://s-edv.com/anleitungen/mysql-postgresql-backup-automatisieren-cron-cloud) 5. [Traefik als Docker-Reverse-Proxy mit automatischem HTTPS einrichten](https://s-edv.com/anleitungen/traefik-docker-reverse-proxy-https-einrichten) 6. [Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only für den Produktivbetrieb](https://s-edv.com/anleitungen/docker-compose-absichern-secrets-healthchecks-non-root) Offizielle Quellen: [LiteLLM Proxy Deployment Dokumentation](https://docs.litellm.ai/docs/proxy/deploy) · [LiteLLM GitHub-Repository (BerriAI/litellm)](https://github.com/BerriAI/litellm) · [Virtual Keys & Cost Tracking](https://docs.litellm.ai/docs/proxy/virtual_keys) · [Config.yaml Struktur](https://docs.litellm.ai/docs/proxy/configs)