DisPatch und meine KI-Tools in Docker ausführen: Eine Datei, ein Befehl

Ich betreibe meine eigene KI-Chat-App, DisPatch, für meine Familie. Bis zu diesem Monat bedeutete die Installation Python, ein virtuelles Umfeld sowie eine Service-Datei. Mittlerweile wird DisPatch als Docker-Image ausgeliefert – die gesamte Einrichtung besteht nur aus einer Datei und einem Befehl auf Ihrem eigenen Server. Diese Seite führt Sie Schritt für Schritt durch den Prozess: von einem leeren Ordner bis hin zu einem funktionierenden Chat. Dabei kommt ein kleines KI-Modell zum Einsatz, das direkt auf Ihrem Prozessor läuft – Sie können es also ausprobieren, ohne sich irgendwo anmelden zu müssen.

Jeder Befehl auf dieser Seite wurde von mir am 19.10.2026 ausgeführt. Auf diesem Rechner habe ich kein Docker Desktop installiert; stattdessen nutzte ich Podman 5.8 zusammen mit Docker Compose 5.6 unter Linux. Die Befehle sind identisch; wo Podman zusätzliche Angaben benötigte, weise ich darauf im technischen Teil am Ende hin.

Was Sie am Ende haben

Atlas ist der Standard-Charakter, mit dem ein neuer DisPatch startet. Er beantwortet Fragen und kann mithilfe eines Modells, das Werkzeuge unterstützt, Informationen nachschlagen: Web-Suche, Seitenabruf, Wetterdaten, Wikipedia, Wechselkurse, Uhrzeit sowie einen Taschenrechner. Derselbe Chat ist auch auf dem Handy verfügbar:

Was DisPatch noch alles kann (Profilverwaltung für alle Familienmitglieder, Kindersicht, Backups etc.), erfahren Sie unter dem Artikel zu DisPatch 3.0. Diese Seite beschreibt lediglich die Einrichtung.

Schritt 1: Docker installieren

• Windows oder Mac: Installieren Sie Docker Desktop und starten Sie es einmal.
• Linux: Installieren Sie Docker Engine sowie das Compose-Plugin – entweder über Ihre Distribution oder gemäß den Docker-Anweisungen.

Überprüfen Sie die Funktionsfähigkeit, indem Sie ein Terminal öffnen (PowerShell unter Windows) und docker compose version eingeben. Jede Version-Nummer bedeutet, dass Sie bereit sind.

Schritt 2: Ordner anlegen und Datei erstellen

Erstellen Sie einen Ordner namens dispatch und speichern Sie darin folgende Datei als docker-compose.yml:

services:
  dispatch:
    image: ghcr.io/laserlloyd/dispatch_chat:main
    ports:
      - "8765:8765"
    volumes:
      - dispatch-data:/data
    restart: unless-stopped
    init: true
    stop_grace_period: 30s

  # Optional: ein kleines KI-Modell, das auf Ihrem Prozessor läuft – keine Anmeldung nötig.
  # Löschen Sie diesen Block, falls Sie stattdessen Ollama, LM Studio oder einen Cloud-Dienst nutzen wollen.
  model:
    image: ghcr.io/ggml-org/llama.cpp:server-b11723
    command: ["-hf", "unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M", "--jinja",
              "--host", "0.0.0.0", "--port", "8080", "--ctx-size", "8192"]
    environment:
      LLAMA_CACHE: /models
    volumes:
      - model-files:/models
    restart: unless-stopped

volumes:
  dispatch-data:
  model-files:

Zwei Services: dispatch ist die Chat-App; model ist der Server von llama.cpp, der beim ersten Start das Qwen3 4B Instruct-Modell (2,5 GB) herunterlädt und speichert. Ihre Chats werden in einem Speichervolumen namens dispatch-data gespeichert – dieses bleibt auch nach Updates oder Neustarts erhalten.

"8765:8765" ermöglicht es anderen Geräten im Netzwerk, DisPatch zu nutzen – genau das wollen Sie für einen Familien-Chat. Falls Sie den Chat vorerst nur auf diesem Computer nutzen möchten, geben Sie stattdessen "127.0.0.1:8765:8765" ein.

Schritt 3: Starten

Öffnen Sie im Terminal den Ordner dispatch und geben Sie Folgendes ein:

docker compose up -d
docker compose ps

Beim ersten Start werden die beiden Images sowie das Modell heruntergeladen – geben Sie dem System also etwas Zeit. Auf meinem Rechner antwortete DisPatch bereits 5 Sekunden nach dem Laden des Images; der Modell-Server benötigte bei meiner Verbindung etwa 20 Sekunden, um das Modell zu laden. docker compose ps sollte beide Services als Up anzeigen.

Schritt 4: Account erstellen

Öffnen Sie im Browser http://localhost:8765. Ein neuer DisPatch ist gesperrt, bis ein Besitzer eingerichtet wurde; da die App in einem Container läuft, wird ein einmaliger Einrichtungstoken abgefragt. Lesen Sie diesen Token aus dem Log:

docker compose logs dispatch | grep "SETUP TOKEN"

Falls grep nicht verfügbar ist (Windows), führen Sie docker compose logs dispatch aus und suchen Sie nach der Zeile, die mit SETUP TOKEN: beginnt. Der Token ändert sich bei jedem Neustart von DisPatch und verliert danach seine Gültigkeit.

Ein Passwort muss mindestens 8 Zeichen enthalten. Der PIN-Code ist optional und dient zum schnellen Entsperren. Falls Sie einen setzen, schreibt DisPatch einen Wiederherstellungscode in seine Daten – diesen sollten Sie an einem sicheren Ort speichern:

docker compose exec dispatch cat /data/RECOVERY-CODE.txt

Schritt 5: KI verbinden

Schritt 2 des Assistenten sucht nach einem Modell-Server auf demselben Computer. Innerhalb von Docker findet er den model-Service jedoch nicht automatisch – geben Sie ihn daher manuell ein:

Feld	Einzutragen
Typ	OpenAI-compatible
Adresse	http://model:8080/v1
API-Schlüssel	leer lassen
Standardmodell	unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_K_M

Möchten Sie stattdessen ein Cloud-Modell nutzen? Wählen Sie es im entsprechenden Feld aus und fügen Sie Ihren Schlüssel ein. Ich habe dies mit einem OpenAI-kompatiblen Cloud-Anbieter getestet: „Testen und speichern“ listete dort die verfügbaren Modelle auf; Atlas antwortete anschließend über diesen Server. Der Schlüssel wird in DisPatchs eigenen Daten gespeichert – nicht in der Compose-Datei.

Schritt 6: Abschließen und Hallo sagen

Die restlichen Schritte sind kurz. Die Sprachfunktion ist ein separates Add-on, das Sie überspringen können; „Familie“ dient zum Hinzufügen weiterer Nutzer (das können Sie später auch noch tun). Im Bereich „Netzwerk“ wählen Sie aus, wer Zugriff auf DisPatch haben soll – wählen Sie hier dieselbe Option wie zuvor bei der Port-Einstellung.

Klicken Sie auf Abschließen. Falls die Seite danach immer noch das Formular zur Erstellung des Besitzer-Accounts anzeigt, laden Sie sie neu. Dies ist ein Darstellungsfehler in der aktuellen Version – der Account wurde bereits angelegt; nur bleibt das alte Formular sichtbar. Wählen Sie anschließend links Atlas aus, klicken Sie auf +, um einen neuen Chat zu starten, und stellen Sie eine Frage.

Um die App vom Handy aus über dasselbe WLAN zu nutzen, öffnen Sie http://<your computer's address>:8765. Für die Installation auf dem Homescreen, Benachrichtigungen sowie die Mikrofonnutzung wird HTTPS benötigt – dazu mehr im technischen Teil.

Das war die gesamte Einrichtung. Alles Weitere dient dazu, tiefergehende Informationen zu erhalten, Ihre Daten zu schützen oder meine anderen Tools hinzuzufügen.

Wie die einzelnen Komponenten zusammenarbeiten

Das DisPatch-Image läuft als gewöhnlicher Benutzer (UID 1000), nicht als Root. Alle Schreibvorgänge erfolgen in /data, welches dem Volume dispatch-data entspricht: Die SQLite-Datenbank, Uploads, Avatare, Einstellungen sowie die stündlichen Backups werden dort gespeichert. Entfernt man den Container, gehen keine Daten verloren; löscht man jedoch das Volume, ist alles weg.

Der Image-Tag main bezieht sich auf die Hauptentwicklungslinie des DisPatch-Repositories. Am 19.10.2026 existierten die Tags main sowie jeweils ein sha-<commit>-Tag pro Build; bislang gibt es noch keine Versionsnummern-Tags. Falls Sie wünschen, dass das Image unverändert bleibt, nutzen Sie ein sha--Tag von der Paketseite. Verfügbar sind Images für 64-Bit-Intel/AMD sowie ARM; ich habe das Intel/AMD-Image verwendet.

Ihre Daten: Sichern, wiederherstellen, sicher aktualisieren

Stoppen Sie zunächst DisPatch, damit die Datenbank vollständig geschrieben wird, und kopieren Sie anschließend das Volume in eine Datei:

docker compose stop dispatch
docker run --rm -v dispatch_dispatch-data:/data:ro -v "$PWD":/backup alpine \
  tar czf /backup/dispatch-backup.tgz -C /data .
docker compose start dispatch

Compose benennt das Volume nach dem Ordner – ein Ordner namens dispatch ergibt also dispatch_dispatch-data; mit docker volume ls erhalten Sie den tatsächlichen Namen. Bei meinem Test mit ein paar Chats entstand eine 3,7 MB große Datei.

Zur Wiederherstellung in ein neues Volume (ich habe meins so wiederhergestellt und anschließend einen zweiten DisPatch-Instanz gestartet: derselbe Besitzer, dieselben 8 Nachrichten):

docker volume create dispatch_dispatch-data
docker run --rm -v dispatch_dispatch-data:/data -v "$PWD":/backup:ro alpine \
  sh -c 'tar xzf /backup/dispatch-backup.tgz -C /data && chown -R 1000:1000 /data'
docker compose up -d

Kopieren Sie chats.db nicht einfach aus einem laufenden Container: Aktuelle Nachrichten befinden sich bis zum Stoppen von DisPatch in der Datei chats.db-wal.

Aktualisierungen erfordern zwei Befehle. Bei einer bereits gefüllten Installation führte ich docker compose down, pull sowie up -d aus; Besitzer und alle Nachrichten blieben erhalten, es wurde kein neues Einrichtungstoken ausgegeben.

docker compose pull
docker compose up -d

Erstellen Sie vor einer großen Aktualisierung ein Backup: DisPatch migriert seine Datenbank beim Start; ältere Images können diese möglicherweise nicht mehr lesen.

Standard-Sicherheitseinstellungen – und eine Einstellung, die Sie prüfen sollten

• Gesperrt bis ein Besitzer angelegt ist. Bis zum Abschluss des ersten Schritts im Einrichtungs-Assistenten sieht das Netzwerk nur eine Anmelde-Seite; zur Erstellung des Besitzers wird das Token aus den Logs benötigt.
• Nicht angemeldete Besucher erhalten die „Eingeschränkte“-Ansicht. Das überraschte mich beim Testen: Aus einem Browser, bei dem ich mich nie angemeldet hatte, konnte ich Atlas öffnen und Antworten erhalten. So ist es in DisPatch 3.0 vorgesehen (Gäste werden wie ein „Eingeschränktes“-Profil behandelt; standardmäßig 200 Antworten pro Tag); diese Antworten nutzen jedoch Ihre KI-Verbindung. Falls DisPatch in Ihrem Netzwerk mit einem kostenpflichtigen Cloud-Key läuft, ändern Sie unter „Einstellungen → Alle Einstellungen → Personen & Profile“ den Eintrag „Ein Gerät, das sich nicht angemeldet hat“ auf Nur Anmeldebildschirm.
• Wer Zugriff erhält, bestimmt die Port-Konfiguration. "8765:8765" erlaubt Zugriff für das gesamte Netzwerk; "127.0.0.1:8765:8765" begrenzt den Zugriff auf diesen Rechner. Der Container selbst lauscht stets auf alle Adressen innerhalb seines eigenen Netzwerks.
• HTTPS müssen Sie selbst einrichten. Das offizielle docker-compose.yml enthält ein optionales Caddy-Proxy (--profile proxy) für eine echte Domain samt Zertifikaten; ich habe dies in diesem Test nicht ausprobiert. Falls Sie nginx vorwärts schalten, müssen Sie proxy_set_header Host $host; beibehalten – sonst lädt der Chat zwar, aktualisiert sich aber nicht mehr (DisPatch prüft, ob der Browser-Origin mit dem Host-Header übereinstimmt).
• Der Modell-Server verwendet kein Schlüsselwort. Sein Port wird in der Konfiguration nicht veröffentlicht; somit kann nur DisPatch ihn erreichen. Fügen Sie unter ports: im Abschnitt model nichts hinzu, es sei denn, Sie geben llama.cpp auch ein --api-key.

Die vollständige Docker-Anleitung zu DisPatch – inklusive Bind-Mounts, Benutzer-IDs sowie der Agent-Integration, die in Containern nicht gut funktioniert – finden Sie unter docs/deploy-docker.md im Repository.

Integration meiner weiteren Tools

Jedes meiner anderen Tools besitzt ein deploy/compose/compose.yml in seinem Repository. Da die Images noch nicht im Registry verfügbar sind, klonen Sie das Repository und nutzen anschließend --build. Jeder Build dauerte hier unter einer Minute – die Basis-Images waren bereits heruntergeladen. Am 19.10.2026 baute ich jeweils alle Tools aus einem frischen GitHub-Klon:

Tool	Beschreibung	Image	Port	Getestet wurde:
DisPatch	die Chat-App	veröffentlicht, 599 MB	8765	alles oben Genannte
MailForge	E-Mail-Assistent, der niemals eigenständig versendet	gebaut, 420 MB	8090	Dashboard öffnet sich; kein Postfach verknüpft
InfoForge + Kiwix	Offline-Suche in Wikipedia für KI-Antworten	gebaut, 128 MB; dazu Kiwix 66 MB	keiner (Kiwix nutzt 8090)	doctor- und search-Funktionen anhand einer 23 MB großen Wikipedia-Datei
ThemeForge	Vorschau-Seite für Themes	gebaut, 13,8 MB	8185	Seite öffnet sich
StudioForge	GPU-Modell-Server	gebaut, 568 MB (Vulkan)	1234, 8080, 1235	Lieferte ein Modell auf einer AMD-Integrierten GPU; siehe unten
CrucibleForge	Modell-Benchmark-Tool	gebaut, 129 MB	8777	Startete und öffnete sich; kein Benchmark lief
TransForge	Übersetzung von Websites	gebaut	keiner	In diesem Test nicht überprüft

Die Größenangaben stammen von Podman; die Compose-Dateien der Tools veröffentlichen ihre Ports standardmäßig nur auf 127.0.0.1, es sei denn, Sie ändern dies.

MailForge

MailForge verschlüsselt die Passwörter Ihrer Postfächer mit einem von Ihnen gewählten Schlüsselring-Passwort. Dieses kann nicht wiederhergestellt werden – daher sollten Sie es in einem Passwort-Manager speichern. Außerdem müssen Sie LLM_BASE_URL auf Ihren eigenen Modell-Server einstellen (die unten angegebene Adresse 192.0.2.10 steht dabei für die Serveradresse). Der Standardport ist 1234 auf dem Docker-Host; alle Anfragen von MailForge werden an diesen Port gesendet.

git clone https://github.com/LaserLloyd/MailForge.git
cd MailForge
read -rsp 'MailForge Schlüsselring-Passphrase: ' MAILFORGE_KEYRING_PASSWORD; export MAILFORGE_KEYRING_PASSWORD
LLM_BASE_URL=http://192.0.2.10:1234/v1 \
  docker compose -f deploy/compose/compose.yml up -d --build
docker compose -f deploy/compose/compose.yml logs app | grep "MailForge UI"

Die ausgegebene Log-Zeile enthält eine Adresse im Format http://127.0.0.1:8090/?token=…; öffnen Sie diese in einem Browser.

InfoForge und die offline verfügbare Wikipedia

Legen Sie eine .zim-Datei aus der Kiwix-Bibliothek in den Ordner deploy/compose/zims/ ab und geben Sie ihr einen Namen in der Datei infoforge.config.yaml (kopieren Sie diese aus infoforge.config.example.yaml). Zum Testen habe ich die 23 MB große „Chemistry by Wikipedia“-Datei verwendet.

git clone https://github.com/LaserLloyd/InfoForge.git
cd InfoForge/deploy/compose
docker compose up -d kiwix
docker compose --profile cli build infoforge
docker compose --profile cli run --rm infoforge doctor
docker compose --profile cli run --rm infoforge search "Edelgas"

Die Suche funktioniert auch ganz ohne KI-Modell:

[1] Edelgas  (Score: 19,0; 4222 Zeichen)
[2] Gas  (Score: 16,0; 1586 Zeichen)
[3] Verbindung aus Edelgas  (Score: 10,5; 2045 Zeichen)

Der Befehl infoforge ask benötigt einen Modellserver unter der Adresse base_url. Mit der Platzhalter-Adresse besteht der Befehl doctor alle Prüfungen – außer „llm primary“, was korrekt ist.

ThemeForge

git clone https://github.com/LaserLloyd/ThemeForge.git
cd ThemeForge
docker compose -f deploy/compose/compose.yml up -d --build

Öffnen Sie anschließend http://localhost:8185.

## Ein GPU-Modell-Server: StudioForge

StudioForge ist mein eigener Modell-Server. Er führt Modelle auf einer Grafikkarte aus, verarbeitet mehrere Modelle sowie mehrere Clients gleichzeitig. Ab Version 2.0 erfordert er für jeden Client ein Besitzerkonto sowie einen API-Schlüssel. Das Image des Servers befindet sich noch nicht in einem Registry – daher wird es in diesem Schritt erstellt.

Ich dachte eigentlich, ich würde hier „Nur NVIDIA“ schreiben. Der Mini-PC, den ich getestet habe, verfügt jedoch nicht über eine NVIDIA-Grafikkarte – lediglich über AMDs integrierte Radeon-GPU im Ryzen AI 9 365-Prozessor. Trotzdem habe ich das Vulkan-Image erstellt, die GPU übergeben und es funktionierte: Bei der ersten Ausführung lud StudioForge den passenden, bereits kompilierten llama.cpp-Engine-Code von GitHub herunter, testete ihn und stellte anschließend Qwen3 4B bereit – wobei alle Schichten auf der GPU verarbeitet wurden. Die Geschwindigkeit lag dabei bei 23 bis 28 Tokens pro Sekunde. Zum Vergleich: Der oben beschriebene CPU-only-model-Service erreichte mit demselben Modell nur 22 Tokens pro Sekunde. Auf diesem Chip entlastet die GPU also den Prozessor mehr, als dass sie die Antwortzeiten verkürzt.

git clone https://github.com/LaserLloyd/StudioForge.git
cd StudioForge/deploy/compose
cp env.example .env
# In der Datei .env: SF_BACKEND=vulkan, SF_MODELS=/Pfad/zu/Ihren/GGUF-Dateien,
#          SF_OWNER_PASSWORD (ein Passwort mit mindestens 10 Zeichen),
#          SF_VIDEO_GID und SF_RENDER_GID – die Zahlen aus: getent group video render
docker compose -f compose.yml -f compose.vulkan.yml build
docker compose -f compose.yml -f compose.vulkan.yml up -d
docker compose -f compose.yml -f compose.vulkan.yml exec studioforge \
  studioforge keys create --name dispatch --scope inference

Der letzte Befehl gibt einen Schlüssel einmal aus. Das Kontrollpanel befindet sich unter http://localhost:8080 (Benutzer owner, Ihr Passwort). Bei einer NVIDIA-Grafikkarte lautet die Datei compose.cuda.yml sowie der Parameter SF_BACKEND=cuda; diesen Pfad habe ich hier nicht getestet – außerdem ist das CUDA-Image deutlich größer.

DisPatch und StudioForge im Zusammenspiel

Im Repository von DisPatch befindet sich die Datei deploy/compose/stack.yml, mit der beide Dienste in einem Netzwerk gestartet werden und die Verbindung zwischen DisPatch und StudioForge automatisch eingerichtet wird. Standardmäßig versucht das System, ein noch nicht öffentlich verfügbares StudioForge-Image herunterzuladen – daher müssen Sie es stattdessen auf das Image umleiten, das Sie gerade erstellt haben. Folgende Einstellungen habe ich zu stack.env hinzugefügt:

git clone https://github.com/LaserLloyd/DisPatch_Chat.git
cd DisPatch_Chat
cp deploy/compose/stack.env.example deploy/compose/stack.env
# Hinzufügen zu deploy/compose/stack.env:
#   DISPATCH_IMAGE=ghcr.io/laserlloyd/dispatch_chat:main
#   STUDIOFORGE_IMAGE=ghcr.io/laserlloyd/studioforge:2.0.1-vulkan
#   STUDIOFORGE_MODELS=/pfad/zu/ihren/gguf-dateien
#   STACK_MODEL=<die Modell-ID, die StudioForge anzeigt>
#   SF_OWNER_PASSWORD (dasselbe 10+ Zeichen langes Owner-Passwort)

Die Stack-Datei reserviert eine NVIDIA-GPU. Für AMD- oder Intel-Hardware unter Verwendung von Vulkan habe ich stattdessen die Datei stack-amd.yml verwendet:

services:
  studioforge:
    deploy: !reset {}
    devices: ["/dev/dri:/dev/dri"]
    group_add: ["39", "105"]   # Ihre Video- und Render-Gruppennummern

docker compose -f deploy/compose/stack.yml -f stack-amd.yml \
  --env-file deploy/compose/stack.env up -d
docker compose -f deploy/compose/stack.yml -f stack-amd.yml \
  --env-file deploy/compose/stack.env exec studioforge \
  studioforge keys create --name dispatch --scope inference

Anschließend beenden Sie den DisPatch-Setup-Assistenten wie beschrieben, öffnen „Einstellungen“ → „Verbindungen“, klicken auf „Bearbeiten“ bei der StudioForge-Verbindung, fügen den Schlüssel ein und klicken auf „Testen“.

Die Modell-ID erhalten Sie über curl -H "Authorization: Bearer <key>" http://localhost:1234/v1/models bzw. im Reiter „Modelle“ im Panel. Falls Ihre Modelle in einem Download-Ordner von Hugging Face liegen, ist die ID der vollständige Pfad zum Ordner – dieser ist zwar lang, funktioniert aber einwandfrei.

## Häufige Probleme

• Seite nach Abschluss neu laden. In der von mir getesteten Version bleibt das Formular „Erstellen eines Owner-Kontos“ nach Schließen des Assistenten auf dem Bildschirm. Das Konto existiert bereits; laden Sie die Seite neu.
• Der Assistent findet das Modell nicht von selbst. Innerhalb von Docker sucht er nur im eigenen Container, nicht in anderen Diensten. Geben Sie stattdessen http://model:8080/v1 ein.
• Kleine Modelle und Abfragen. Bei Qwen2.5 1,5B gab Atlas manchmal eine erfundene Zeile wie „Web-Suche: …“ aus, anstatt das Tool aufzurufen. Das 4B-Modell aus der obigen Datei rief die Wetterabfrage hingegen jedes Mal korrekt auf – größere Modelle sind hier besser geeignet.
• Der Wiederherstellungscode existiert nur bei PIN-Einstellung. Ohne PIN gibt es keine Datei RECOVERY-CODE.txt, obwohl der Checkliste des Assistenten eine solche erwähnt.
• Zwei Tools beanspruchen Port 8090. MailForge sowie kiwix von InfoForge nutzen standardmäßig Port 8090. Bei gleichzeitiger Ausführung müssen Sie HOST_PORT für MailForge bzw. KIWIX_PORT für kiwix festlegen.
• Erster Start von StudioForge erfordert GitHub. Es lädt den llama.cpp-Engine über die GitHub-API herunter; pro IP-Adresse sind dabei maximal 60 anonyme Anfragen pro Stunde erlaubt. Mein erster Versuch erreichte diese Grenze; das schlanke Vulkan-Image versuchte anschließend, den Engine-Code selbst zu kompilieren – was es nicht konnte (es enthält kein git), und meldete can_serve: false. Nach einem Neustart nach Ablauf der Limitierung funktionierte alles. Laut StudioForge-Logmeldung erhöht die Angabe von GITHUB_TOKEN in .env das Limit.
• docker compose down -v löscht Ihre Chats. Der einfache Befehl down tut dies nicht.
• Podman-Nutzer: Auf Fedora und anderen SELinux-Systemen müssen Sie dem Mount-Pfad des Backup-Ordners :z hinzufügen ("$PWD":/backup:z). Zudem lehnte Podman mit Docker Compose die Compose-Dateien der Tools ab, deren Healthcheck-Block keine test:-Zeile enthielt („ein Healthcheck-Kommando muss definiert sein“); ich fügte das Test-Kommando aus den jeweiligen Dockerfiles in einer kleinen Überschreibungsdatei hinzu. Für kiwix ohne Root-Rechte ist KIWIX_USER=0 erforderlich. Docker-Nutzer können diesen Punkt ignorieren.

## Was ich nicht getestet habe

• Docker Desktop unter Windows oder Mac. Ich nutzte Podman mit Docker Compose unter Linux, ausschließlich x86-64.
• Ollama oder LM Studio außerhalb von Docker auf demselben Rechner. Unter Docker Desktop wäre die Adresse http://host.docker.internal:11434/v1 für Ollama; dieser Server muss Verbindungen aus dem Container zulassen – das habe ich nicht überprüft.
• NVIDIA- und ROCm-basierte StudioForge-Images, die Build-Variante mit Sprachfunktion (VOICE=1), das Caddy-HTTPS-Profil sowie TransForge.
• InfoForge’s ask-Funktion in Kombination mit einem Modell sowie ein Benchmark-Lauf mit CrucibleForge.

DisPatch auf GitHub StudioForge MailForge InfoForge

Weitere Informationen: DisPatch 3.0: Familienprofile und Setup-Assistent, DisPatch, StudioForge sowie Wie man ein LLM dazu bringt, jedes Projekt an das eigene System anzupassen.