---
title: "SillyTavern mit Docker installieren: LLM-Frontend für Rollenspiel und Prompt-Steuerung"
date: 2026-08-14T09:17:54+02:00
modified: 2026-11-10T18:12:56+01:00
category: kuenstliche-intelligenz
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/sillytavern-docker-llm-frontend
reading_time: 10
personalize_url: "https://s-edv.com/anleitungen/sillytavern-docker-llm-frontend#pgid={pgid}&server_ip={server_ip}&ihr_marker={ihr_marker}"
variables:
  - name: pgid
    label: "Gruppen-ID (PGID)"
    default: "1000"
  - name: server_ip
    label: "Server ip"
    default: "SERVER-IP"
  - name: password
    label: "Passwort (password)"
    generated_in_browser: true
  - name: ihr_marker
    label: "Ihr marker"
    default: "IHR-MARKER"
---

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

## 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 |
| --- | --- | --- |
| `{{pgid}}` | Gruppen-ID (PGID) | `1000` |
| `{{server_ip}}` | Server ip | `SERVER-IP` |
| `{{password}}` | Passwort (password) | wird im Browser des Lesers zufällig erzeugt |
| `{{ihr_marker}}` | Ihr marker | `IHR-MARKER` |

Link mit eigenen Werten: https://s-edv.com/anleitungen/sillytavern-docker-llm-frontend#pgid=100&server_ip=SERVER-IP&ihr_marker=IHR-MARKER

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.

**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.

**Kurzfassung:** Ordner `/opt/sillytavern` anlegen, `.env` und `compose.yaml` nach dem offiziellen Vorbild schreiben, mit `docker compose up -d` starten. Unter Linux mit Docker CE blockiert SillyTavern danach auch Aufrufe vom eigenen Host mit „Forbidden“ (HTTP 403), bis Sie das Gateway des Docker-Netzes in die Whitelist in `config/config.yaml` eintragen. Für Zugriffe aus dem LAN kommt das Client-Netz dazu, außerdem Basic-Auth mit eigenem Passwort. Ollama im selben Compose-Netz erreichen Sie unter `http://ollama:11434`. Gesichert werden die Ordner `config` und `data` bei gestopptem Container.

## 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](https://s-edv.com/anleitungen/docker-compose-linux-selfhosting-grundlage).
- [ ] 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](https://s-edv.com/anleitungen/ollama-open-webui-docker-lokales-llm).
- [ ] 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

| Eigenschaft | Wert |
| --- | --- |
| Image | `ghcr.io/sillytavern/sillytavern:1.19.0` (Release vom 14.09.2026) |
| Port | 8000/tcp (HTTP) |
| Laufzeit im Image | Node.js 24 (v24.21.0 im Image 1.19.0) |
| Datenbank | keine, alle Daten als Dateien |
| Lizenz | AGPL-3.0 |

| Ordner (Host → Container) | Inhalt |
| --- | --- |
| `./config → /home/node/app/config` | `config.yaml` mit Whitelist, Basic-Auth, Port |
| `./data → /home/node/app/data` | Charakterkarten, Chats, Einstellungen, API-Schlüssel (`secrets.json`) |
| `./plugins → /home/node/app/plugins` | Server-Plugins (optional) |
| `./extensions → …/extensions/third-party` | UI-Erweiterungen für alle Benutzer (optional) |

## Schritt 1: Projektordner und .env anlegen

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

```bash
$ sudo mkdir -p /opt/sillytavern/{config,data,plugins,extensions}
$ cd /opt/sillytavern
$ sudo chown -R {{pgid}}:{{pgid}} 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.

```ini
# /opt/sillytavern/.env
ST_VERSION=1.19.0
PUID={{pgid}}
PGID={{pgid}}
```

Den Wert für `ST_VERSION` entnehmen Sie den [Release Notes](https://github.com/SillyTavern/SillyTavern/releases). Gleitende Tags wie `latest` oder `staging` (Entwicklungszweig) sollten Sie im Betrieb nicht verwenden, weil ein unbeabsichtigter Pull dann eine neue Version einspielt.

> **Prüfen:** `ls -ln /opt/sillytavern` zeigt die Ordner `config`, `data`, `plugins` und `extensions` mit Besitzer `{{pgid}} {{pgid}}`, `cat .env` die drei Variablen.

## 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.

```yaml
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](https://s-edv.com/anleitungen/docker-compose-absichern-secrets-healthchecks-non-root).

> **Prüfen:** `docker compose config --quiet` endet ohne Ausgabe und mit Exit-Code 0. Meldet Compose eine leere Variable, liegt die `.env` nicht im selben Ordner.

## Schritt 3: Container starten

```bash
$ 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:

```plaintext
Mode: PUID/PGID (UID:{{pgid}} GID:{{pgid}})
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.

> **Prüfen:** Nach spätestens einer Minute zeigt `docker compose ps` den Status `Up … (healthy)`. `curl -I http://localhost:8000` antwortet unter Linux zu diesem Zeitpunkt mit `HTTP/1.1 403 Forbidden`: Der Dienst läuft, die Whitelist weist die Anfrage ab.

## 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`:

```bash
$ 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:

Datei: `config/config.yaml`

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

```bash
$ 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.

![Fehlerseite Forbidden von SillyTavern: Verbindung von 172.18.0.1, weitergeleitet von 192.168.1.50, wurde von der Whitelist blockiert](https://s-edv.com/uploads/2026/10/f0f1ece540f9c1cf311f77fff24ce739b5b95ea997f428bdf371ee0d178a3b18-1024.png)
*Fehlerseite bei fehlendem Whitelist-Eintrag: SillyTavern nennt die Proxy-Adresse und die weitergeleitete Client-Adresse.*

> **Prüfen:** `curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8000` liefert nun `200`. Ein Gerät aus dem eingetragenen Netz öffnet `http://{{server_ip}}:8000` und sieht den Begrüßungsdialog. Eine Adresse außerhalb der Liste erhält weiter „Forbidden“, im Log steht dann `Blocked connection from …`.

## 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:

```yaml
basicAuthMode: true
basicAuthUser:
  username: "st-admin"
  password: "{{password}}"
```

```bash
$ 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](https://s-edv.com/anleitungen/caddy-reverse-proxy-automatisches-https-anleitung) oder ein VPN davor. Für getrennte Konten pro Person bietet SillyTavern zusätzlich `enableUserAccounts` (Mehrbenutzermodus).

> **Prüfen:** Im Test lieferte ein Aufruf ohne Zugangsdaten `401` mit dem Header `WWW-Authenticate: Basic realm="SillyTavern"`, mit falschem Passwort ebenfalls `401`, mit den richtigen Daten `200`. Prüfen Sie das mit `curl -s -o /dev/null -w '%{http_code}\n' -u st-admin:{{password}} http://localhost:8000`. Im Browser erscheint ein Anmeldedialog.

## 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`:

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

```bash
$ 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`.

![SillyTavern-Bereich API-Verbindungen mit API-Typ Ollama, API-URL http://ollama:11434 und verbundenem Modell smollm2:135m](https://s-edv.com/uploads/2026/10/c3379e9f4f44ccf6241690a9d5876162457991b8b1bb95c64b727bfdb714bf24-1024.png)
*API-Verbindungen: Ollama über den Dienstnamen angebunden, der grüne Punkt zeigt das verbundene Modell.*

> **Prüfen:** Neben dem Modellnamen erscheint ein grüner Punkt. Öffnen Sie über die Charakterverwaltung den mitgelieferten Beispielcharakter Seraphina und senden Sie eine kurze Nachricht: Das Modell antwortet im Chat. Im Test mit dem kleinen Modell `smollm2:135m` kam die Antwort nach wenigen Sekunden.

![SillyTavern-Chat mit dem Beispielcharakter Seraphina: Testnachricht mit Marker und Antwort des Modells](https://s-edv.com/uploads/2026/10/d0319b3b2edbb2c6d6a08563325389b384284c4f9b338ef4ba267dd65740a083-1024.png)
*Testchat mit dem Beispielcharakter: Die Nachricht mit dem Marker wird später zum Prüfen der Wiederherstellung genutzt.*

## 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:

```bash
$ 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:

```bash
$ 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.

> **Prüfen:** `tar tzf /root/sillytavern-DATUM.tar.gz | grep -c chats` zeigt Einträge größer null. Nach einer Wiederherstellung findet `grep -rl "{{ihr_marker}}" data/default-user/chats` die Chatdatei, und `docker compose ps` meldet `healthy`.

## 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:

```bash
$ 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.

> **Prüfen:** `docker compose logs sillytavern | grep "SillyTavern 1."` zeigt die neue Versionsnummer, `docker compose ps` meldet `healthy`, und Ihre Chats sind in der Oberfläche vorhanden.

## 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](https://docs.sillytavern.app/administration/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](https://s-edv.com/anleitungen/vps-absichern-haerten-ufw-ssh-keys-fail2ban). Besser ist der Zugang über ein VPN. Die Firewall-Grundlagen stehen in [Linux-Server absichern mit UFW und Fail2ban](https://s-edv.com/anleitungen/linux-server-absichern-ufw-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](https://s-edv.com/anleitungen/ollama-open-webui-docker-lokales-llm) oder ein Gateway wie [LiteLLM](https://s-edv.com/anleitungen/litellm-docker-llm-gateway) zuständig.

## Weiterführende Anleitungen und Quellen

- [Ollama und Open WebUI mit Docker: lokales KI-Sprachmodell ohne Cloud](https://s-edv.com/anleitungen/ollama-open-webui-docker-lokales-llm)
- [LiteLLM mit Docker installieren: selbstgehosteter KI-Gateway](https://s-edv.com/anleitungen/litellm-docker-llm-gateway)
- [AnythingLLM installieren: lokale KI-Zentrale mit RAG-Workspaces](https://s-edv.com/anleitungen/anythingllm-installieren-rag-workspaces-ollama-docker)
- [Docker-Netzwerke und Volumes verstehen](https://s-edv.com/anleitungen/docker-netzwerke-volumes-verstehen)
- [SillyTavern-Dokumentation: Docker-Installation](https://docs.sillytavern.app/installation/docker/)
- [SillyTavern-Dokumentation: config.yaml und Umgebungsvariablen](https://docs.sillytavern.app/administration/config-yaml/)
- [Offizielle docker-compose.yml im Release-Zweig](https://github.com/SillyTavern/SillyTavern/blob/release/docker/docker-compose.yml)
- [SillyTavern Releases](https://github.com/SillyTavern/SillyTavern/releases)