Diese Anleitung zeigt Dir Schritt für Schritt, wie Du Lobe Chat mit Docker einrichtest – eine moderne, designstarke KI-Chat-Plattform, die Du komplett selbst hostest. Lobe Chat bündelt viele Provider (OpenAI, Anthropic, lokale Modelle über Ollama u. v. m.) in einer aufgeräumten Web-UI, kann mit Plugins und MCP-Marktplatz erweitert werden und bringt in der großen Ausbaustufe eine Wissensdatenbank (RAG), Datei-Speicher und Mehrbenutzer-Anmeldung mit. Du hast die Wahl zwischen zwei Wegen: einer Schnellvariante mit einem einzigen Container (docker run) und einer Server-DB-Variante per Docker Compose mit Postgres, Authentifizierung und S3-kompatiblem Speicher. Zielgruppe sind Admins im Mittelstand und ambitionierte Heimserver-Nutzer auf einem Linux-Server mit Docker. Als designstarke Alternative ergänzt Lobe Chat Plattformen wie LibreChat oder Open WebUI.

Kurzfassung: Für den schnellen Test reicht ein einziger Container mit Zugangscode. Für den Dauerbetrieb mit Login, Verlauf-Sync und RAG nimmst Du die Server-DB-Variante per Compose. Die Kernbefehle:

docker run -d -p 3210:3210 -e OPENAI_API_KEY=sk-xxxx -e ACCESS_CODE=DEIN-CODE lobehub/lobe-chat
docker compose up -d                          # Server-DB-Variante starten
docker compose pull && docker compose up -d   # Update einspielen

Die Web-UI läuft danach auf Port 3210. Ohne ACCESS_CODE bzw. Auth ist die Instanz offen erreichbar.

Voraussetzungen

Lobe Chat selbst ist schlank – die Rechenlast liegt beim LLM-Provider. Die Anforderungen unterscheiden sich je nach Variante:

Hardware (Schnellvariante): bereits 1–2 GB RAM reichen, da nur der Frontend-/Proxy-Container läuft und die Inferenz extern stattfindet (z. B. OpenAI).
Hardware (Server-DB-Variante): plane mehr ein, da zusätzlich PostgreSQL, Redis, ein S3-kompatibler Speicher und optional SearXNG laufen – sinnvoll sind 2 CPU-Kerne und 4 GB RAM aufwärts plus ausreichend Storage für Datenbank und Dateien.
Betriebssystem: Linux-Server mit Docker und Docker Compose, z. B. Debian 12 oder Ubuntu 24.04.
Datenbank: für die Server-DB-Variante wird PostgreSQL 14+ mit der pgvector-Erweiterung benötigt (für die Wissensdatenbank/RAG). Das hier genutzte Image paradedb/paradedb bringt das mit.
GPU – nur für lokale Modelle: Für Lobe Chat selbst brauchst Du KEINE GPU. Eine GPU ist nur relevant, wenn Du auf derselben Maschine lokale Modelle über Ollama servierst. Dann installierst Du das nvidia-container-toolkit und reichst die GPU an den Ollama-Container durch. Ollama läuft zwar auch rein auf CPU, aber spürbar langsamer; für 7B-Modelle sind 8 GB+ VRAM komfortabel. Cloud-Provider wie OpenAI/Anthropic brauchen lokal keine GPU.
Netzwerk/Domain: Die UI lauscht auf Port 3210. Für den Zugriff von außen brauchst Du eine Domain und idealerweise einen Reverse-Proxy mit HTTPS (siehe Schritt 7).

Docker-Grundlagen setzen wir voraus. Wenn Du beim Aufbau von Compose-Stacks noch unsicher bist, hilft Dir vorab die Anleitung Docker Compose: Grundlagen und Stacks.

Schritt 1: Schnellstart mit docker run

Der schnellste Weg ist ein einziger Container mit dem Image lobehub/lobe-chat. Diese Variante hat KEINE eigene Server-Datenbank: Konversationen werden im Browser gespeichert (kein geräteübergreifender Sync, keine serverseitige Wissensdatenbank). Ideal zum Ausprobieren oder für eine Einzelperson:

docker run -d -p 3210:3210 \
  -e OPENAI_API_KEY=sk-xxxx \
  -e ACCESS_CODE=DEIN-CODE \
  --name lobe-chat \
  lobehub/lobe-chat

Danach öffnest Du http://SERVER-IP:3210 und gibst den ACCESS_CODE ein. Wichtige Umgebungsvariablen für diese Variante:

OPENAI_API_KEY – dein API-Schlüssel des Standard-Providers (hier OpenAI).
OPENAI_PROXY_URL – optionale abweichende API-Basis-URL, falls Du einen Proxy oder einen OpenAI-kompatiblen Endpunkt nutzt.
ACCESS_CODE – ein Zugangscode, der die Instanz vor fremdem Zugriff schützt. Ohne diesen Code (oder Auth in der großen Variante) ist die UI offen erreichbar.

Für den Dauerbetrieb solltest Du das Image mit einem festen Versions-Tag pinnen (Stand 2026-01-25 ist die aktuelle Version 1.143.3) und --restart unless-stopped ergänzen, damit der Container nach einem Reboot wieder hochkommt. Wenn Du nur testen willst, bist Du hier fertig – für Login, Verlauf-Sync und RAG geht es ab Schritt 2 mit der Server-DB-Variante weiter.

Schritt 2: Lokale Modelle über Ollama anbinden (optional)

Statt eines Cloud-Providers kannst Du lokale Modelle über Ollama nutzen und bleibst damit komplett im eigenen Haus. Lobe Chat spricht Ollama über eine OpenAI-kompatible Schnittstelle an. Läuft Ollama direkt auf dem Docker-Host, setzt Du:

docker run -d -p 3210:3210 \
  -e OLLAMA_PROXY_URL=http://host.docker.internal:11434/v1 \
  -e ACCESS_CODE=DEIN-CODE \
  --name lobe-chat \
  lobehub/lobe-chat

Hinweis zur Erreichbarkeit: host.docker.internal klappt auf Docker Desktop direkt. Auf einem reinen Linux-Server musst Du es entweder per --add-host host.docker.internal:host-gateway bereitstellen oder die Docker-Bridge-Adresse http://172.17.0.1:11434/v1 verwenden. Sauberer ist es, Ollama als eigenen Service in dasselbe Compose-Netz zu legen und ihn dann unter seinem Servicenamen anzusprechen (z. B. http://ollama:11434/v1). Wie Du Ollama containerisiert betreibst, zeigt die Anleitung Ollama mit Open WebUI in Docker betreiben. Genau hier ist auch die GPU relevant: Ollama nutzt mit nvidia-container-toolkit die GPU; ohne läuft es auf CPU – funktionsfähig, aber langsamer.

Schritt 3: Server-DB-Variante – Verzeichnis und compose.yaml anlegen

Für Login, geräteübergreifenden Verlauf, Datei-Upload und Wissensdatenbank brauchst Du das Datenbank-Image lobehub/lobe-chat-database – NICHT das normale lobehub/lobe-chat. Lege zunächst ein Projektverzeichnis an:

mkdir -p $HOME/lobe-chat
cd $HOME/lobe-chat

Die folgende compose.yaml ist vollständig und lauffähig. Sie startet Lobe Chat (Datenbank-Image), PostgreSQL mit pgvector (über paradedb), Redis, einen S3-kompatiblen Speicher (RustFS) samt Bucket-Initialisierung und SearXNG für die Online-Suche. Alle veränderlichen Werte stehen oben in der .env (Schritt 4) und werden hier referenziert:

services:
  postgres:
    image: paradedb/paradedb:latest-pg17     # Postgres 17 inkl. pgvector fuer RAG
    container_name: lobe-postgres
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${LOBE_DB_NAME}
    volumes:
      - ./data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5
    restart: always

  redis:
    image: redis:7-alpine
    container_name: lobe-redis
    volumes:
      - redis_data:/data
    restart: always

  rustfs:
    image: rustfs/rustfs:latest               # S3-kompatibler Objektspeicher
    container_name: lobe-rustfs
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      RUSTFS_ACCESS_KEY: ${RUSTFS_ACCESS_KEY}
      RUSTFS_SECRET_KEY: ${RUSTFS_SECRET_KEY}
    volumes:
      - rustfs-data:/data
    restart: always

  rustfs-init:
    image: minio/mc:latest                    # legt einmalig den Bucket an
    depends_on:
      - rustfs
    entrypoint: >
      /bin/sh -c "
      until (mc alias set lobe http://rustfs:9000 ${RUSTFS_ACCESS_KEY} ${RUSTFS_SECRET_KEY}) do sleep 2; done;
      mc mb --ignore-existing lobe/${RUSTFS_LOBE_BUCKET};
      mc anonymous set download lobe/${RUSTFS_LOBE_BUCKET};
      exit 0;
      "
    restart: "no"

  searxng:
    image: searxng/searxng:latest             # Online-Suche fuer Lobe Chat
    container_name: lobe-searxng
    restart: always

  lobe:
    image: lobehub/lobe-chat-database:latest   # WICHTIG: Datenbank-Image, nicht lobe-chat
    container_name: lobe-chat
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started
      rustfs:
        condition: service_started
    ports:
      - "3210:3210"
    environment:
      APP_URL: ${APP_URL}
      KEY_VAULTS_SECRET: ${KEY_VAULTS_SECRET}
      AUTH_SECRET: ${AUTH_SECRET}
      NEXT_AUTH_SSO_PROVIDERS: credentials
      DATABASE_URL: ${DATABASE_URL}
      REDIS_URL: ${REDIS_URL}
      OPENAI_API_KEY: ${OPENAI_API_KEY}
      S3_ENDPOINT: ${S3_ENDPOINT}
      S3_BUCKET: ${S3_BUCKET}
      S3_ACCESS_KEY_ID: ${S3_ACCESS_KEY_ID}
      S3_SECRET_ACCESS_KEY: ${S3_SECRET_ACCESS_KEY}
      S3_ENABLE_PATH_STYLE: 1
      SEARXNG_URL: ${SEARXNG_URL}
      AUTH_ALLOWED_EMAILS: ${AUTH_ALLOWED_EMAILS}
    restart: always

volumes:
  rustfs-data:
    driver: local
  redis_data:
    driver: local

Die Persistenz steckt in drei Stellen: das Bind-Verzeichnis ./data hält die Postgres-Datenbank, das Named Volume rustfs-data die hochgeladenen Dateien und redis_data den Cache. Diese drei sicherst Du im Backup (Schritt 8). Statt :latest solltest Du für Produktion feste Versions-Tags setzen (z. B. lobehub/lobe-chat-database:1.143.3), damit Updates vorhersehbar bleiben.

Schritt 4: .env erstellen und Secrets erzeugen

Lege im selben Verzeichnis die Datei .env an. Sie enthält Secrets und alle Verbindungs-URLs. Die kritischen Geheimnisse erzeugst Du mit:

openssl rand -base64 32   # je einmal fuer KEY_VAULTS_SECRET und AUTH_SECRET

Damit befüllst Du die .env. Die Defaults aus der offiziellen Vorlage sind übernommen; ersetze Passwörter und Schlüssel durch eigene Werte:

# --- Basis ---
APP_URL=https://DEINE-DOMAIN.de
LOBE_DB_NAME=lobechat
POSTGRES_PASSWORD=DEIN-DB-PASSWORT

# --- Secrets (mit openssl rand -base64 32 erzeugen) ---
KEY_VAULTS_SECRET=ERZEUGTER-32-BYTE-WERT-NIE-AENDERN
AUTH_SECRET=ERZEUGTER-32-BYTE-WERT

# --- Datenbank / Cache ---
DATABASE_URL=postgresql://postgres:DEIN-DB-PASSWORT@postgres:5432/lobechat
REDIS_URL=redis://redis:6379

# --- LLM-Provider ---
OPENAI_API_KEY=sk-xxxx

# --- Auth (E-Mail-Allowlist fuer den Login) ---
AUTH_ALLOWED_EMAILS=admin@DEINE-DOMAIN.de

# --- S3 / Objektspeicher (RustFS) ---
RUSTFS_ACCESS_KEY=admin
RUSTFS_SECRET_KEY=DEIN-S3-SECRET
RUSTFS_LOBE_BUCKET=lobe
S3_ENDPOINT=https://s3.DEINE-DOMAIN.de
S3_BUCKET=lobe
S3_ACCESS_KEY_ID=admin
S3_SECRET_ACCESS_KEY=DEIN-S3-SECRET

# --- Online-Suche ---
SEARXNG_URL=http://searxng:8080

Drei Werte musst Du unbedingt richtig setzen, sonst funktioniert die Instanz nicht oder verliert Daten:

KEY_VAULTS_SECRET niemals nachträglich ändern. Damit werden die hinterlegten Provider-API-Schlüssel verschlüsselt. Änderst Du den Wert später, sind alle gespeicherten Schlüssel unbrauchbar.
APP_URL und S3_ENDPOINT dürfen NICHT localhost sein, sobald die Instanz von außen erreichbar ist. Trage hier die echten, von außen aufrufbaren URLs ein – sonst scheitern Login-Redirects und das Laden hochgeladener Dateien (Bilder, Anhänge).
AUTH_ALLOWED_EMAILS beschränkt, wer sich registrieren bzw. anmelden darf. Lässt Du Auth offen und ohne Allowlist, kann sich jeder ein Konto anlegen.

Die Standard-Defaults der Vorlage lauten u. a. APP_URL=http://localhost:3210, LOBE_DB_NAME=lobechat, RUSTFS_ACCESS_KEY=admin und RUSTFS_LOBE_BUCKET=lobe – für den lokalen Test okay, für Produktion anpassen.

Schritt 5: Stack starten und prüfen

Die offizielle Vorlage liefert ein Setup-Skript mit, das compose.yaml und .env interaktiv vorbereitet. Du kannst es nutzen oder – wie oben – die Dateien selbst anlegen. Anschließend startest Du den Stack:

# Variante A: offizielles Setup-Skript (legt compose.yaml/.env an)
bash setup.sh

# Variante B: eigene Dateien aus Schritt 3/4 nutzen
docker compose up -d
docker compose ps
docker compose logs -f lobe   # Logs live mitlesen, mit Strg+C beenden

Der rustfs-init-Container läuft einmal durch, legt den Bucket an und beendet sich – das ist gewollt (Status exited). Wenn lobe, postgres, redis und rustfs als running erscheinen, ist die UI unter Port 3210 bzw. unter deiner APP_URL erreichbar. Den verwendeten Image-Tag prüfst Du mit:

docker inspect --format '{{.Config.Image}}' lobe-chat

Schritt 6: Web-UI-Ersteinrichtung und Kernfunktionen

Öffne https://DEINE-DOMAIN.de (Server-DB-Variante) bzw. http://SERVER-IP:3210 (Schnellvariante). So gehst Du vor:

Anmelden/Registrieren: In der Server-DB-Variante legst Du über den Login (NextAuth, Methode credentials) ein Konto an – nur E-Mail-Adressen aus AUTH_ALLOWED_EMAILS sind zugelassen. In der Schnellvariante gibst Du den ACCESS_CODE ein.
Provider-Schlüssel prüfen: Unter den Einstellungen findest Du die KI-Anbieter. Hier sind die per .env gesetzten Schlüssel hinterlegt (verschlüsselt über KEY_VAULTS_SECRET); zusätzliche Provider wie Anthropic oder Ollama trägst Du hier nach.
Wissensdatenbank/RAG: Lade Dokumente hoch – Lobe Chat legt sie im S3-Speicher ab und erzeugt über pgvector Embeddings. Im Chat kannst Du dann eine Wissensdatenbank als Kontext zuweisen und mit deinen Dokumenten chatten.
Plugins/MCP-Marktplatz: Über den Marktplatz aktivierst Du Plugins und MCP-Server (Model Context Protocol), z. B. Websuche (via SearXNG), Code-Tools oder eigene Integrationen. So erweiterst Du den Funktionsumfang ohne eigenen Code.
Online-Suche: Dank SEARXNG_URL kann der Chat live im Web recherchieren.

Schritt 7: Reverse-Proxy und HTTPS

Port 3210 (und erst recht der S3-Port 9000) gehören NICHT ungeschützt ins Internet. Stelle der UI einen Reverse-Proxy mit TLS voran, der nach außen auf 443 lauscht und intern weiterleitet. Beispiel für nginx:

server {
    listen 443 ssl;
    server_name DEINE-DOMAIN.de;

    ssl_certificate     /etc/letsencrypt/live/DEINE-DOMAIN.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/DEINE-DOMAIN.de/privkey.pem;

    client_max_body_size 100M;   # fuer Datei-Uploads in die Wissensdatenbank

    location / {
        proxy_pass http://127.0.0.1:3210;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Damit die Dienste nicht direkt erreichbar sind, bindest Du die Port-Mappings in der compose.yaml an die Loopback-Adresse, z. B. - "127.0.0.1:3210:3210". Wichtig: APP_URL in der .env muss exakt der von außen aufgerufenen HTTPS-Adresse entsprechen, und der S3_ENDPOINT braucht ebenfalls eine eigene, öffentlich erreichbare HTTPS-URL (eigener vHost), damit Bilder und Anhänge im Browser laden.

Schritt 8: Update-Workflow und Backup

Ein Update besteht aus zwei Befehlen. Dank Volumes bleiben Datenbank, Dateien und Cache erhalten:

docker compose pull && docker compose up -d

Ziehe vor jedem Update ein Backup, besonders wenn Du :latest nutzt. Sichere die drei Persistenz-Stellen plus die Konfiguration:

docker compose down
tar czf lobe-backup-$(date +%F).tar.gz \
  -C $HOME/lobe-chat data compose.yaml .env
docker compose up -d

Für die Named Volumes rustfs-data (hochgeladene Dateien) und redis_data nutzt Du einen Hilfscontainer:

docker run --rm \
  -v lobe-chat_rustfs-data:/data \
  -v $PWD:/backup \
  alpine tar czf /backup/rustfs.tgz -C /data .

Der Name des Volumes ist in der Regel PROJEKTVERZEICHNIS_rustfs-data – prüfe ihn mit docker volume ls. Wichtig fürs Restore: die .env mit dem unveränderten KEY_VAULTS_SECRET gehört zwingend ins Backup, sonst lassen sich die verschlüsselten Provider-Schlüssel nach der Wiederherstellung nicht mehr entschlüsseln.

Troubleshooting

Login/Datei-Speicher funktioniert nicht, obwohl Container laufen: Wahrscheinlich läuft das falsche Image. Die Server-DB-Funktionen gibt es NUR mit lobehub/lobe-chat-database, nicht mit lobehub/lobe-chat.
Gespeicherte API-Schlüssel plötzlich ungültig: Das KEY_VAULTS_SECRET wurde geändert. Es muss über die gesamte Lebensdauer der Instanz konstant bleiben – stelle den ursprünglichen Wert aus dem Backup wieder her.
Bilder/Anhänge laden nicht, Login-Redirect schlägt fehl: APP_URL oder S3_ENDPOINT stehen noch auf localhost. Trage die echten, von außen erreichbaren HTTPS-URLs ein.
Instanz ist ungeschützt offen: In der Schnellvariante fehlt der ACCESS_CODE; in der Server-DB-Variante ist keine Auth/Allowlist konfiguriert. Setze ACCESS_CODE bzw. AUTH_ALLOWED_EMAILS und stelle einen Reverse-Proxy davor.
Ollama nicht erreichbar: Auf Linux zeigt host.docker.internal nicht automatisch auf den Host. Nutze --add-host host.docker.internal:host-gateway, die Bridge-Adresse http://172.17.0.1:11434/v1 oder lege Ollama als Service ins selbe Compose-Netz.
RAG/Wissensdatenbank ohne Treffer: Es wird Postgres mit pgvector benötigt (PostgreSQL 14+). Das paradedb-Image bringt das mit – prüfe, dass der Postgres-Container gesund startet (healthcheck).

Häufige Fragen

Schnellvariante oder Server-DB-Variante – was nehme ich?

Zum Ausprobieren oder für eine Einzelperson reicht die Schnellvariante mit docker run und ACCESS_CODE; die Daten liegen dann im Browser. Sobald Du Login, geräteübergreifenden Verlauf, Datei-Upload oder die Wissensdatenbank (RAG) brauchst, nimmst Du die Server-DB-Variante mit dem lobe-chat-database-Image und Postgres/Redis/S3.

Brauche ich für Lobe Chat eine GPU?

Nein. Lobe Chat selbst ist nur die Plattform – die Rechenlast liegt beim LLM. Eine GPU ist nur relevant, wenn Du lokale Modelle über Ollama auf derselben Maschine servierst; dann hilft das nvidia-container-toolkit. Mit Cloud-Providern wie OpenAI/Anthropic brauchst Du lokal gar keine GPU.

Warum darf ich KEY_VAULTS_SECRET nicht ändern?

Mit diesem Schlüssel verschlüsselt Lobe Chat die hinterlegten Provider-API-Schlüssel (Key Vault). Änderst Du ihn nachträglich, lassen sich die gespeicherten Schlüssel nicht mehr entschlüsseln und gehen verloren. Erzeuge ihn einmal mit openssl rand -base64 32 und sichere ihn im Backup.

Kann ich lokale Modelle statt OpenAI verwenden?

Ja. Über OLLAMA_PROXY_URL bindest Du Ollama (OpenAI-kompatibel) an und nutzt lokale Modelle. Wie Du Ollama in Docker betreibst, zeigt die Anleitung Ollama mit Open WebUI in Docker betreiben.

Wie unterscheidet sich Lobe Chat von AnythingLLM, LibreChat oder Open WebUI?

Lobe Chat ist die besonders designstarke Plattform mit Plugin-/MCP-Marktplatz und vielen Providern in einer aufgeräumten UI. Open WebUI ist eng mit Ollama verzahnt, AnythingLLM ist eine turnkey RAG-Anwendung. Wenn Dein Schwerpunkt das Chatten mit Dokumenten ist, lohnt der Blick auf AnythingLLM mit Docker: mit den eigenen Dokumenten chatten (RAG).

Wie sichere ich meine Daten richtig?

Sichere das Bind-Verzeichnis ./data (Postgres), das Volume rustfs-data (Dateien) und die .env mit dem unveränderten KEY_VAULTS_SECRET. Mit diesen drei Bausteinen stellst Du die Instanz vollständig auf einem anderen Host wieder her.

Fazit

Mit Lobe Chat und Docker hast Du zwei klare Wege: für den schnellen Start einen einzigen Container mit docker run und ACCESS_CODE, für den ernsthaften Dauerbetrieb die Server-DB-Variante per Compose mit Postgres (pgvector), Redis, S3-Speicher und SearXNG. Entscheidend sind drei Dinge: das richtige Image (lobe-chat-database für alle Server-Funktionen), ein stabil bleibendes KEY_VAULTS_SECRET und echte, von außen erreichbare URLs in APP_URL/S3_ENDPOINT hinter einem Reverse-Proxy mit HTTPS. Damit betreibst Du eine moderne, designstarke KI-Chat-Plattform DSGVO-bewusst und reproduzierbar im eigenen Haus – als überzeugende Ergänzung zu LibreChat oder Open WebUI.

Weiterführende Anleitungen und Quellen

Passende Anleitungen aus unserem Wissensbereich:

Docker Compose: Grundlagen und Stacks – Basis für die hier verwendete compose.yaml.
Ollama mit Open WebUI in Docker betreiben – lokales LLM-Backend für Lobe Chat.
AnythingLLM mit Docker: mit den eigenen Dokumenten chatten (RAG) – die RAG-fokussierte Alternative.
Alle Anleitungen der Kategorie Künstliche Intelligenz

Quellen (offizielle Doku/Repo, Stand 2026):