SillyTavern mit Docker installieren: Das Feature-reichste LLM-Frontend für Power-User

Wer lokale KI-Sprachmodelle oder Cloud-APIs ernsthaft nutzen will, stößt früher oder später an die Grenzen einfacher Chat-Interfaces. SillyTavern füllt diese Lücke: Das Open-Source-Projekt bietet eine vollwertige Umgebung für Charakter- und Persona-Verwaltung, Lorebooks, erweiterte Prompt-Steuerung, Rollenspiel-Szenarien und nahtlose Anbindung an praktisch alle gängigen LLM-Backends – ob Ollama auf dem lokalen Rechner oder OpenAI in der Cloud. Mit mehr als 29.000 GitHub-Stars und aktivem Entwicklungsteam (AGPL-3.0) ist es die erste Wahl für anspruchsvolle Heimanwender, KI-Enthusiasten und Entwickler, die volle Kontrolle über ihr LLM-Erlebnis brauchen. Diese Anleitung führt dich plattformneutral durch die Docker-Installation: ein einzelner Container, keine externe Datenbank, alle Daten dauerhaft in gemounteten Volumes.

Voraussetzungen

1. Docker Engine 24+ mit Docker Compose Plugin v2 (Befehl: docker compose) auf einem Linux-Host, einer VM oder einem NAS mit Docker-Unterstützung. Noch nicht installiert? Siehe Docker und Docker Compose auf Linux installieren.
2. Internetzugang zu ghcr.io für den Image-Download (das Image liegt ausschließlich auf der GitHub Container Registry – kein Docker Hub).
3. Mindestens 1 GB RAM (empfohlen 2 GB+) und 2 GB freier Speicher für Image und Nutzerdaten.
4. Einen laufenden LLM-Backend-Dienst (z. B. Ollama mit Docker) oder einen Cloud-API-Key (OpenAI, Anthropic, OpenRouter usw.) – mindestens eines davon, sonst gibt es nichts zu chatten.
5. Optional: Reverse Proxy (Nginx, Caddy, Traefik) für HTTPS, falls SillyTavern über das LAN oder Internet erreichbar sein soll.
6. Hinweis Windows: Auf Windows ist der Docker-Betrieb durch WSL2-Virtualisierung deutlich komplexer. Das SillyTavern-Projekt selbst empfiehlt auf Windows die native Node.js-Installation. Wer Docker Desktop trotzdem nutzt, sollte sich auf zusätzliche Netzwerk-Eigenheiten einstellen.

Eckdaten auf einen Blick

Schritt 1: Projektordner anlegen

Lege einen dedizierten Ordner für den SillyTavern-Stack an. Alle weiteren Dateien (compose.yaml, .env) landen dort, die Volumes als Unterordner daneben.

mkdir -p /opt/sillytavern
cd /opt/sillytavern
mkdir -p config data plugins extensions

Der Befehl mkdir -p config data ... legt die Volume-Verzeichnisse vorab an. Das verhindert einen häufigen Fehler: Wenn Docker ein fehlendes Verzeichnis selbst anlegt, gehört es root – was Berechtigungsprobleme verursacht.

Wer den Container als Nicht-Root-Benutzer betreiben will (empfohlen auf Mehrbenutzersystemen), setzt die Rechte jetzt:

chown -R 1000:1000 config data plugins extensions

Verifizieren: ls -la /opt/sillytavern/ sollte die vier Unterordner (config, data, plugins, extensions) mit dem richtigen Besitzer anzeigen.

Schritt 2: .env-Datei erstellen

Die .env-Datei hält alle konfigurierbaren Parameter an einem Ort. So muss bei Port-Änderungen oder einem anderen Image-Tag nur diese Datei angepasst werden, nicht die compose.yaml.

# SillyTavern – Umgebungsvariablen
# Datei: /opt/sillytavern/.env

# Image-Tag: latest (stabil) oder staging (Entwicklungszweig)
SILLYTAVERN_VERSION=latest

# Externer Port – ändern, wenn 8000 bereits belegt ist
PUBLIC_PORT=8000

# Volume-Pfade (relativ zur compose.yaml)
CONFIG_PATH=./config
DATA_PATH=./data
PLUGINS_PATH=./plugins
EXTENSIONS_PATH=./extensions

# Nicht-Root-Ausführung (auskommentiert = Standard UID/GID des Images)
# PUID=1000
# PGID=1000

Verifizieren: cat /opt/sillytavern/.env zeigt die gespeicherten Variablen ohne Fehlermeldung. Stelle sicher, dass die Datei kein BOM-Zeichen enthält (bei Windows-Editoren aufpassen).

Schritt 3: compose.yaml erstellen

Die compose.yaml definiert den Service, liest alle variablen Werte aus der .env und konfiguriert den Healthcheck. SillyTavern braucht keinen Datenbank-Companion – ein einziger Service genügt.

services:
  sillytavern:
    image: ghcr.io/sillytavern/sillytavern:${SILLYTAVERN_VERSION:-latest}
    container_name: sillytavern
    hostname: sillytavern
    environment:
      - NODE_ENV=production
      - FORCE_COLOR=1
      - SILLYTAVERN_HEARTBEATINTERVAL=30
      # Nicht-Root optional – PUID/PGID in .env setzen und einkommentieren:
      # - PUID=${PUID:-1000}
      # - PGID=${PGID:-1000}
    ports:
      - "${PUBLIC_PORT:-8000}:8000"
    volumes:
      - "${CONFIG_PATH:-./config}:/home/node/app/config"
      - "${DATA_PATH:-./data}:/home/node/app/data"
      - "${PLUGINS_PATH:-./plugins}:/home/node/app/plugins"
      - "${EXTENSIONS_PATH:-./extensions}:/home/node/app/public/scripts/extensions/third-party"
    healthcheck:
      test: ["CMD", "node", "src/healthcheck.js"]
      interval: 30s
      timeout: 10s
      start_period: 20s
      retries: 3
    restart: unless-stopped

Wichtige Designentscheidungen dieser Konfiguration im Überblick: NODE_ENV=production aktiviert optimiertes Logging und Performance. SILLYTAVERN_HEARTBEATINTERVAL=30 versetzt den Healthcheck in einen 30-Sekunden-Takt – ohne diesen Wert bleibt der Status dauerhaft „starting". restart: unless-stopped sorgt dafür, dass der Container nach einem Neustart des Hosts automatisch wieder startet, außer er wurde manuell gestoppt.

Das offizielle docker-compose.yml aus dem Release-Branch des Repos verwendet hardcodierte Pfade. Die hier gezeigte Variante mit .env-Referenzen ist eine praxisnahe Erweiterung für bessere Wartbarkeit – fachlich identisch, aber flexibler. Die offizielle Quelle bleibt in jedem Zweifelfall maßgeblich.

Verifizieren: docker compose config im Projektordner gibt die aufgelöste Compose-Konfiguration ohne Fehler aus. Erscheinen Variablen-Warnungen, stimmt der Pfad zur .env nicht.

Schritt 4: Container starten und Erst-Start prüfen

Starte den Stack aus dem Projektordner heraus:

cd /opt/sillytavern
docker compose up -d

Docker lädt das Image von ghcr.io herunter (ca. 400–600 MB beim ersten Mal) und startet den Container im Hintergrund. Nach dem ersten Start erzeugt SillyTavern automatisch die Datei ./config/config.yaml mit Standardwerten.

Status prüfen:

docker compose ps

Erwartete Ausgabe (nach ca. 20–30 Sekunden):

NAME           IMAGE                                      STATUS
sillytavern    ghcr.io/sillytavern/sillytavern:latest    Up (healthy)

Logs prüfen:

docker compose logs -f sillytavern

Suche nach Zeilen wie SillyTavern is listening on port 8000. Fehlermeldungen zu fehlenden Volumes oder Berechtigungen erscheinen ebenfalls hier.

Verifizieren: curl -I http://localhost:8000 gibt HTTP/1.1 200 OK oder eine Weiterleitung zurück. Alternativ: Browser auf http://localhost:8000 öffnen – die SillyTavern-Oberfläche sollte erscheinen.

Schritt 5: Whitelist und Zugangskontrolle konfigurieren

SillyTavern ist standardmäßig auf 127.0.0.1 beschränkt. Für den Zugriff aus dem LAN oder von einem anderen Rechner muss die Whitelist in ./config/config.yaml erweitert werden.

Öffne die frisch erzeugte Datei:

nano /opt/sillytavern/config/config.yaml

Suche den Abschnitt whitelist und ergänze die eigene Client-IP oder das Subnetz:

whitelist:
  - 127.0.0.1
  - 192.168.1.0/24   # eigenes Heimnetz – Subnetz anpassen!

Für Passwortschutz (empfohlen, sobald der Dienst über das LAN erreichbar ist) aktiviere die Basic-Auth:

basicAuthMode: true
basicAuthUser:
  username: dein-benutzername
  password: dein-sicheres-passwort

Nach jeder Änderung an config.yaml muss der Container neu gestartet werden:

docker compose restart sillytavern

Verifizieren: Öffne http://<host-ip>:8000 von einem anderen Gerät im LAN. Mit aktivierter Basic-Auth erscheint ein Login-Dialog. Ohne Passwortschutz lädt die Oberfläche direkt. docker compose ps zeigt weiterhin Up (healthy).

Schritt 6: LLM-Backend verbinden

SillyTavern ist ohne ein verbundenes Backend nur eine leere Oberfläche. Die API-Verbindung wird direkt in der Web-UI unter dem Stecker-Symbol (API Connections) konfiguriert.

Ollama (lokal auf dem Docker-Host): Wähle als API-Typ „Ollama" und trage als URL ein:

1. Docker Desktop (Windows/Mac): http://host.docker.internal:11434
2. Linux Docker CE ohne Docker Desktop: http://172.17.0.1:11434 (Gateway-IP ermitteln: docker network inspect bridge | grep Gateway)

Denke daran, die Gateway-IP auch in der config.yaml-Whitelist einzutragen – sonst kann SillyTavern zwar eine Anfrage schicken, aber der Rückweg ist geblockt. Mehr zu Docker-Netzwerken und Gateway-Routing erklärt die Anleitung Docker-Netzwerke und Volumes richtig nutzen.

Cloud-APIs (OpenAI, Anthropic, OpenRouter usw.): Wähle den passenden API-Typ und trage den API-Key direkt in der UI ein. Der Key wird in ./config/ gespeichert – achte auf die Sicherheit des Volume-Verzeichnisses.

Weitere Backends wie KoboldCpp, LM Studio, TabbyAPI und Oobabooga TextGen WebUI folgen dem gleichen Prinzip: API-Typ auswählen, URL des Backends eintragen, Verbindung testen.

Verifizieren: Klicke in der SillyTavern-UI auf den „Connect"-Button neben dem gewählten Backend. Bei erfolgreicher Verbindung erscheint ein grünes Häkchen und die verfügbaren Modelle werden aufgelistet. Starte einen Testchat mit einem beliebigen Charakter.

Schritt 7: Updates und Backups

Das Update-Verfahren ist dank der persistenten Volumes risikoarm. Trotzdem empfiehlt sich ein kurzes Backup der Nutzerdaten vor jedem Update:

# Backup vor dem Update
cp -r /opt/sillytavern/config /opt/sillytavern/config.bak
cp -r /opt/sillytavern/data /opt/sillytavern/data.bak

# Image aktualisieren und Container neu starten
cd /opt/sillytavern
docker compose pull
docker compose up -d

Docker Compose lädt das neue Image, stoppt den alten Container und startet einen neuen – die Volumes bleiben unberührt, alle Charakterkarten und Chat-Verläufe sind sofort wieder verfügbar.

Wer immer auf dem aktuellsten Entwicklungsstand sein möchte, ändert in der .env den Tag auf SILLYTAVERN_VERSION=staging. Staging entspricht dem aktiven Entwicklungszweig und kann instabil sein – für den Alltagsbetrieb bleibt latest die richtige Wahl.

Container stoppen (ohne Datenverlust):

docker compose down

Verifizieren: Nach dem Update zeigt docker compose ps erneut Up (healthy). In den Logs (docker compose logs sillytavern | head -20) erscheint die neue Version. Alle Charakterkarten und Einstellungen sind unverändert vorhanden.

Troubleshooting – Typische Fehler

1. Verbindung abgelehnt (Connection refused) auf Port 8000: Der Container läuft, aber die Whitelist in config/config.yaml enthält nur 127.0.0.1. Eigene Client-IP oder das Subnetz hinzufügen, dann docker compose restart sillytavern.
2. config/config.yaml wird nicht erstellt: Das ./config-Verzeichnis existiert nicht oder der Container-Prozess hat keine Schreibrechte. Lösung: mkdir -p ./config ./data und chown 1000:1000 ./config ./data auf dem Host ausführen.
3. Ollama nicht erreichbar aus dem Container: localhost im Container zeigt auf den Container selbst, nicht den Host. Auf Docker Desktop host.docker.internal:11434 verwenden, auf Linux Docker CE die Gateway-IP ermitteln: docker network inspect bridge | grep Gateway.
4. Healthcheck schlägt dauerhaft fehl, Container restartet: SILLYTAVERN_HEARTBEATINTERVAL ist nicht gesetzt oder zu niedrig. Wert auf 30 setzen und start_period: 20s in der compose.yaml beibehalten.
5. Image nicht gefunden (Pull-Fehler von ghcr.io): Das Image existiert nicht auf Docker Hub. Die korrekte Registry ist ausschließlich ghcr.io/sillytavern/sillytavern:latest. Tippfehler im Image-Namen prüfen.
6. Berechtigungsfehler beim Schreiben in Volumes (Linux): Der Container-Prozess läuft als UID 1000, die Host-Verzeichnisse gehören root. Lösung: chown -R 1000:1000 ./config ./data oder PUID/PGID in der .env setzen und in der compose.yaml aktivieren.
7. Charakterkarten nach Update verschwunden: Die Volume-Pfade in der compose.yaml wurden verändert oder der Container wurde ohne bestehende Volume-Einträge neu gestartet. Vor jedem Update Backup der ./data-Verzeichnisse erstellen.
8. Plugins funktionieren nicht: Zwei Bedingungen müssen gleichzeitig erfüllt sein: Das ./plugins-Volume muss eingebunden sein und in config.yaml muss enableServerPlugins: true stehen.

Häufige Fragen

Brauche ich eine Datenbank wie PostgreSQL oder Redis?

Nein. SillyTavern speichert alle Daten als Dateien in den gemounteten Volumes (./config und ./data). Es gibt keinen Datenbank-Companion und keinen geheimen Schlüssel im Sinne einer App-Umgebungsvariable.

Kann ich SillyTavern mit Ollama im selben Docker-Netzwerk betreiben?

Ja, das ist sogar eleganter als der Weg über die Host-IP. Definiere ein gemeinsames benutzerdefiniertes Netzwerk in beiden Compose-Stacks oder starte beide in derselben compose.yaml. Dann ist Ollama unter seinem Container-Hostnamen erreichbar, z. B. http://ollama:11434.

Wie sichere ich den Zugang mit Passwort ab?

In ./config/config.yaml die Option basicAuthMode: true setzen sowie basicAuthUser.username und basicAuthUser.password konfigurieren, dann docker compose restart sillytavern. Für HTTPS einen Reverse Proxy vorschalten – Caddy ist besonders einfach, da er Zertifikate automatisch verwaltet. Mehr dazu in der Anleitung Caddy als Reverse Proxy mit automatischem HTTPS.

Kann ich bestehende Charakterkarten importieren?

Ja. Charakterkarten (.png oder .json) einfach in ./data/characters/ kopieren, Chat-Verläufe in ./data/chats/. Nach einem Container-Neustart sind sie in der UI verfügbar. Alternativ funktioniert der Import-Button direkt in der Oberfläche.

Was ist der Unterschied zwischen „latest" und „staging"?

latest folgt dem stabilen Release-Branch und wird für den alltäglichen Betrieb empfohlen. staging entspricht dem aktiven Entwicklungszweig mit den neuesten Features – kann aber instabil sein und eignet sich eher zum Ausprobieren. Wechsel durch Änderung von SILLYTAVERN_VERSION=staging in der .env und anschließendes docker compose pull && docker compose up -d.

Wie schütze ich den Dienst, wenn er ins Internet zeigen soll?

Das SillyTavern-Projekt warnt ausdrücklich davor, den Container direkt ohne Schutzmaßnahmen ins Internet zu exponieren. Minimum: basicAuthMode: true in config.yaml und einen HTTPS-Reverse-Proxy vorschalten. Noch besser: Zugang nur über ein VPN erlauben. Für ein vollständiges Setup empfiehlt sich die Anleitung VPS absichern und härten.

Fazit

SillyTavern ist unter den LLM-Frontends eine eigene Kategorie: Der Funktionsumfang bei Charakter-Verwaltung, Prompt-Engineering und Backend-Flexibilität übertrifft alle einfacheren Alternativen bei Weitem. Die Docker-Installation ist dank des schlanken Einzelcontainers ohne Datenbank-Abhängigkeit überraschend unkompliziert – in zehn Minuten ist der Stack betriebsbereit. Der größte Stolperstein ist die Whitelist-Konfiguration beim LAN-Zugriff, aber die ist nach einmaligem Verständnis trivial. Wer bereits Ollama oder ein anderes lokales Backend betreibt, hat damit sofort einen vollwertigen, selbstgehosteten KI-Arbeitsplatz – ohne Cloud-Abhängigkeit, ohne Abo, ohne Datenweitergabe.

Weiterführende Anleitungen und Quellen

1. Ollama und Open WebUI mit Docker: lokales KI-Sprachmodell ohne Cloud
2. LiteLLM mit Docker installieren: selbstgehosteter KI-Gateway für alle Backends
3. AnythingLLM installieren: lokale KI-Zentrale mit RAG-Workspaces und Ollama
4. Docker und Docker Compose auf Linux installieren – die Self-Hosting-Grundlage

Offizielle Quellen: SillyTavern Offizielle Docker-Dokumentation | Offizielles docker-compose.yml (Release-Branch) | SillyTavern GitHub-Repository