SillyTavern mit Docker installieren: LLM-Frontend für Rollenspiel und Prompt-Steuerung

SillyTavern ist eine Weboberfläche für Sprachmodelle (LLM) mit Charakterkarten, Personas, Lorebooks und feiner Prompt-Steuerung. Die Oberfläche rechnet nicht selbst, sondern spricht mit einem Backend: lokal etwa Ollama oder KoboldCpp, in der Cloud OpenAI, Anthropic oder OpenRouter. Diese Anleitung richtet SillyTavern 1.19.0 mit Docker Compose ein, sichert den Zugang per Whitelist und Basic-Auth ab, bindet Ollama an und zeigt Backup und Wiederherstellung. Alle Schritte wurden auf einem Debian-12-Testhost mit Docker CE nachgestellt.

Voraussetzungen

• Linux-Server, VM oder NAS mit Docker Engine und Compose-Plugin v2 (docker compose version). Einrichtung siehe Docker und Docker Compose auf Linux installieren.
• Architektur x86-64 (amd64) oder ARM64: Das Image ghcr.io/sillytavern/sillytavern:1.19.0 wird für beide Plattformen gebaut.
• Für SillyTavern selbst 1 CPU-Kern und 1 GB RAM. Im Test belegte der Container im Leerlauf rund 120 MB RAM, das Image rund 850 MB Speicher. Planen Sie 2 GB freien Speicher für Image, Chats und Backups ein.
• Ein LLM-Backend: entweder ein Cloud-API-Schlüssel oder ein lokales Modell. Lokale Modelle brauchen den Großteil der Ressourcen: je nach Modellgröße 8 bis 32 GB RAM bzw. eine GPU mit passendem VRAM. Einstieg mit Ollama und Open WebUI mit Docker.
• Zugriff auf ghcr.io. Das Image liegt nur in der GitHub Container Registry, nicht auf Docker Hub.
• Für den Zugriff von außerhalb des LANs zusätzlich ein Reverse Proxy mit HTTPS oder ein VPN.

Eckdaten auf einen Blick

Schritt 1: Projektordner und .env anlegen

Legen Sie den Projektordner mit den vier Datenordnern an. Existieren die Ordner nicht, erzeugt Docker sie als root.

$ sudo mkdir -p /opt/sillytavern/{config,data,plugins,extensions}
$ cd /opt/sillytavern
$ sudo chown -R 1000:1000 config data plugins extensions

Die .env hält die Version und die Benutzer-ID fest. Mit PUID und PGID wechselt das Startskript des Images vom Root-Konto auf diesen Benutzer und passt die Besitzer der eingebundenen Ordner bei Bedarf selbst an.

# /opt/sillytavern/.env
ST_VERSION=1.19.0
PUID=1000
PGID=1000

Den Wert für ST_VERSION entnehmen Sie den Release Notes. Gleitende Tags wie latest oder staging (Entwicklungszweig) sollten Sie im Betrieb nicht verwenden, weil ein unbeabsichtigter Pull dann eine neue Version einspielt.

Schritt 2: compose.yaml erstellen

Die Datei folgt dem offiziellen docker/docker-compose.yml aus dem Release-Zweig. Geändert sind nur der feste Tag aus der .env und PUID/PGID; die Zeile build entfällt, weil das fertige Image verwendet wird.

services:
  sillytavern:
    image: ghcr.io/sillytavern/sillytavern:${ST_VERSION}
    container_name: sillytavern
    hostname: sillytavern
    environment:
      - NODE_ENV=production
      - FORCE_COLOR=1
      - SILLYTAVERN_HEARTBEATINTERVAL=30
      - PUID=${PUID}
      - PGID=${PGID}
    ports:
      - "8000:8000"
    volumes:
      - "./config:/home/node/app/config"
      - "./data:/home/node/app/data"
      - "./plugins:/home/node/app/plugins"
      - "./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

SILLYTAVERN_HEARTBEATINTERVAL=30 lässt SillyTavern alle 30 Sekunden die Datei data/heartbeat.json schreiben. Der Healthcheck prüft diese Datei. Mit dem Wert 0 ist der Heartbeat abgeschaltet. Soll der Dienst nur auf dem Server selbst erreichbar sein, schreiben Sie unter ports "127.0.0.1:8000:8000". Wie Sie Healthchecks, Secrets und den Betrieb ohne Root in Compose-Projekten absichern, zeigt Docker Compose absichern: Secrets, Healthchecks, Non-Root.

Schritt 3: Container starten

$ docker compose up -d
$ docker compose ps
$ docker compose logs sillytavern | head -40

Beim ersten Start kopiert das Image die Vorlage nach config/config.yaml, erzeugt ein Cookie-Secret in data und legt den Benutzer default-user an. Im Log stehen unter anderem diese Zeilen:

Mode: PUID/PGID (UID:1000 GID:1000)
Resource not found, copying from defaults: config.yaml
Failed to resolve whitelist hostname host.docker.internal: getaddrinfo ENOTFOUND host.docker.internal
SillyTavern 1.19.0
SillyTavern is listening on IPv4: 0.0.0.0:8000

Die Meldung zu host.docker.internal ist unter Linux mit Docker CE normal: Diese Namen gibt es nur in Docker Desktop. Die Option whitelistDockerHosts greift deshalb nicht, was in Schritt 4 wichtig wird.

Schritt 4: Whitelist anpassen

SillyTavern lässt per Vorgabe nur 127.0.0.1 und ::1 zu (whitelistMode: true). Ein Aufruf vom Docker-Host kommt im Container aber von der Gateway-Adresse des Docker-Netzes an, nicht von 127.0.0.1. Ermitteln Sie diese Adresse; das Netz heißt nach dem Projektordner sillytavern_default:

$ docker network inspect sillytavern_default --format '{{range .IPAM.Config}}{{.Gateway}}{{end}}'

Tragen Sie das Gateway und das Netz Ihrer Arbeitsplätze in config/config.yaml ein. Die Adressen unten sind Beispiele:

whitelist:
  - ::1
  - 127.0.0.1
  - 172.18.0.1        # Gateway des Docker-Netzes
  - 192.168.1.0/24    # LAN der Arbeitsplätze

$ sudo nano /opt/sillytavern/config/config.yaml
$ docker compose restart sillytavern

Hinter einem Reverse Proxy prüft SillyTavern wegen enableForwardedWhitelist: true zusätzlich die Client-Adresse aus dem Header X-Forwarded-For. Im Test mit vorgeschaltetem Proxy blieb die Seite gesperrt, solange nur das Gateway eingetragen war; erst mit dem Client-Netz kam die Oberfläche.

Schritt 5: Basic-Auth aktivieren

Die Whitelist prüft nur Adressen. Sobald mehrere Personen im Netz arbeiten, gehört ein Passwort davor. Die Vorlage enthält dafür basicAuthMode mit den Beispielwerten user und password, die Sie unbedingt ersetzen:

basicAuthMode: true
basicAuthUser:
  username: "st-admin"
  password: "EIN-LANGES-EIGENES-PASSWORT"

$ docker compose restart sillytavern

Das Passwort steht im Klartext in config.yaml. Beschränken Sie die Leserechte auf dem Host deshalb auf Administratoren. Basic-Auth überträgt die Zugangsdaten ohne Verschlüsselung: Außerhalb des LANs gehört HTTPS über einen Reverse Proxy wie Caddy mit automatischem HTTPS oder ein VPN davor. Für getrennte Konten pro Person bietet SillyTavern zusätzlich enableUserAccounts (Mehrbenutzermodus).

Schritt 6: Ollama anbinden

Am einfachsten läuft Ollama im selben Compose-Projekt. Dann erreicht SillyTavern das Backend über den Dienstnamen, ohne dass Port 11434 nach außen geöffnet wird. Ergänzen Sie unter services:

  ollama:
    image: ollama/ollama:0.40.4
    volumes:
      - ./ollama:/root/.ollama
    restart: unless-stopped

$ docker compose up -d
$ docker compose exec ollama ollama pull llama3.2:3b

Öffnen Sie in SillyTavern das Stecker-Symbol (API-Verbindungen), wählen Sie Textvervollständigung, API-Typ Ollama, tragen Sie als API-URL http://ollama:11434 ein und klicken Sie auf Verbinden. Danach wählen Sie das Modell aus der Liste. Läuft Ollama direkt auf dem Host, nutzen Sie die Gateway-Adresse aus Schritt 4 (etwa http://172.18.0.1:11434); Ollama muss dann auf dieser Adresse lauschen (OLLAMA_HOST). Cloud-Anbieter wählen Sie unter Chat-Abschluss; die Schlüssel speichert SillyTavern in data/default-user/secrets.json.

Schritt 7: Backup und Wiederherstellung

Alles, was zählt, liegt in config (Zugang, Whitelist) und data (Chats, Charaktere, Einstellungen, API-Schlüssel). SillyTavern schreibt laufend in diese Ordner. Stoppen Sie den Container deshalb für die Sicherung kurz:

$ cd /opt/sillytavern
$ docker compose stop sillytavern
$ sudo tar czf /root/sillytavern-$(date +%F).tar.gz config data compose.yaml .env
$ docker compose start sillytavern

Das Archiv enthält mit secrets.json Ihre API-Schlüssel und mit config.yaml das Basic-Auth-Passwort. Lagern Sie es verschlüsselt und nicht auf demselben Server. Zur Wiederherstellung auf einem neuen Host:

$ sudo mkdir -p /opt/sillytavern && cd /opt/sillytavern
$ sudo tar xzf /root/sillytavern-DATUM.tar.gz
$ docker compose up -d

Im Test wurde eine Chatnachricht mit einem Marker geschrieben, gesichert, die Ordner config und data gelöscht und aus dem Archiv zurückgespielt. Danach war der Container wieder healthy, die Whitelist galt weiter, und der Chat mit dem Marker war vollständig vorhanden.

Schritt 8: Updates

Sichern Sie zuerst wie in Schritt 7. Tragen Sie dann die neue Version in die .env ein und laden Sie das Image:

$ sed -i 's/^ST_VERSION=.*/ST_VERSION=NEUE-VERSION/' .env
$ docker compose pull
$ docker compose up -d

Beim Start ergänzt das Init-Skript des Images neue Einstellungen in config.yaml, Ihre Whitelist und Zugangsdaten bleiben stehen. Lesen Sie vor größeren Sprüngen die Release Notes auf geänderte Optionen.

Typische Fehler

„Forbidden“ trotz laufendem Container

Die Adresse fehlt in der Whitelist. Die blockierte Adresse steht auf der Fehlerseite und im Log (Blocked connection from …). Unter Linux fehlt meist das Docker-Gateway, hinter einem Proxy die Client-Adresse aus X-Forwarded-For.

„Failed to resolve whitelist hostname host.docker.internal“

Unter Docker CE erwartbar und harmlos, ersetzt aber den Gateway-Eintrag nicht.

Container bleibt „unhealthy“

data/heartbeat.json wird nicht geschrieben, meist wegen fehlender Schreibrechte. Besitzer von data mit ls -ln prüfen und PUID/PGID setzen.

Ollama: keine Verbindung

localhost zeigt im Container auf SillyTavern selbst. Dienstnamen ollama oder Gateway-Adresse verwenden und mit docker compose exec sillytavern node -e "fetch('http://ollama:11434/api/tags').then(r=>console.log(r.status))" (erwartet: 200) prüfen.

Pull schlägt fehl

Das Image heißt ghcr.io/sillytavern/sillytavern; ohne Registry-Präfix sucht Docker auf Docker Hub.

Warnung zu SSRF im Log

Bei aktivem listen weist SillyTavern auf privateAddressWhitelist hin. Ist der Dienst für nicht vertrauenswürdige Benutzer erreichbar, aktivieren Sie die Option nach der Dokumentation zur config.yaml.

Häufige Fragen

Brauche ich eine Datenbank?

Nein. SillyTavern speichert alles als Dateien in data. Ein einzelner Container reicht.

Kann ich die Whitelist abschalten?

Mit whitelistMode: false ja. Dann schützt nur noch Basic-Auth bzw. der Mehrbenutzermodus. Das ist allenfalls hinter einem VPN vertretbar; im LAN ist eine gepflegte Whitelist plus Passwort die bessere Wahl.

Lassen sich Einstellungen über Umgebungsvariablen setzen?

Ja. Laut Dokumentation überschreiben Variablen mit dem Präfix SILLYTAVERN_ die Werte aus config.yaml, Listen als JSON, etwa SILLYTAVERN_WHITELIST='["127.0.0.1","172.18.0.1"]'. Der Heartbeat in Schritt 2 nutzt genau diesen Weg.

Wie übernehme ich vorhandene Charakterkarten?

Über die Schaltfläche „Importieren“ in der Charakterverwaltung (PNG- oder JSON-Karten) oder durch Kopieren nach data/default-user/characters mit anschließendem Neustart.

Darf SillyTavern direkt ins Internet?

Nicht ohne Schutz. Mindestens Basic-Auth oder Benutzerkonten, HTTPS über einen Reverse Proxy und eine gehärtete Firewall, siehe VPS absichern und härten. Besser ist der Zugang über ein VPN. Die Firewall-Grundlagen stehen in Linux-Server absichern mit UFW und Fail2ban.

Fazit

SillyTavern ist mit einem Container schnell gestartet. Die eigentliche Arbeit liegt in der Zugangskontrolle: Unter Linux sperrt die Whitelist zunächst sogar den eigenen Host aus, hinter einem Proxy zählt zusätzlich die weitergeleitete Client-Adresse. Mit Gateway- und LAN-Eintrag, eigenem Basic-Auth-Passwort, festem Image-Tag und einem regelmäßigen Archiv von config und data läuft das Frontend im Firmen- oder Heimnetz kontrolliert. Für die Modelle selbst bleibt Ollama oder ein Gateway wie LiteLLM zuständig.

Weiterführende Anleitungen und Quellen

• Ollama und Open WebUI mit Docker: lokales KI-Sprachmodell ohne Cloud
• LiteLLM mit Docker installieren: selbstgehosteter KI-Gateway
• AnythingLLM installieren: lokale KI-Zentrale mit RAG-Workspaces
• Docker-Netzwerke und Volumes verstehen
• SillyTavern-Dokumentation: Docker-Installation
• SillyTavern-Dokumentation: config.yaml und Umgebungsvariablen
• Offizielle docker-compose.yml im Release-Zweig
• SillyTavern Releases