Dify mit Docker Compose auf einem VPS selbst hosten

Was Dify ist und wofür Sie den Betrieb einrichten

Dify ist eine selbst hostbare Plattform zum Erstellen von Anwendungen auf Basis großer Sprachmodelle. Sie erhalten eine Weboberfläche zum Entwerfen von Chat-Anwendungen, Agents und Retrieval-Pipelines, eine API für den Aufruf aus Ihrem eigenen Code sowie eine zentrale Verwaltung für Prompts, Datensätze und Model-Keys. Das ist ein Werkzeug, das ein kleines Team auf einem gemeinsamen privaten Fundament betreibt, statt API-Keys über verschiedene Skripte zu verteilen. Wenn Begriffe wie Agent, Tool-Call und Retrieval-Pipeline noch unklar sind, hilft es, diese Konzepte zunächst von Grund auf durchzugehen. Danach wirken die Builder-Oberflächen von Dify wie vertraute Steuerelemente und nicht wie eine Wand unbeschrifteter Schalter.

Der Eigenbetrieb bedeutet, dass Sie viele Komponenten betreiben. Stand Oktober 2026 startet der dokumentierte Standard-Stack von Dify 15 dauerhaft laufende Container sowie eine einmalige Aufgabe, die Dateiberechtigungen setzt und anschließend beendet wird. Sieben davon sind eigene Dify-Dienste: der API-Server, ein WebSocket-Server, ein Hintergrund-Worker, ein Scheduler, das Web-Frontend, ein Plugin-Daemon und ein Agent-Backend. Die übrigen acht sind Abhängigkeiten: eine Postgres-Datenbank, ein Redis-Cache, eine Weaviate-Vektordatenbank, ein nginx-Frontend, zwei Code-Sandboxen und zwei SSRF-Proxys. Docker Compose verbindet alle Komponenten, aber das ist ein vollständiger Stack. Die dokumentierte Mindestanforderung von Dify liegt bei 4 GiB RAM und zwei CPU-Kernen. Wenn auf diesem VPS zusätzlich andere Dienste laufen sollen, dimensionieren Sie ihn anhand gemessener Werte und nicht anhand beworbener Mindestanforderungen. Die tatsächlichen RAM-Untergrenzen von PhotoPrism und Immich liegen deutlich über ihren veröffentlichten Mindestwerten. Ein gemeinsam betriebener Fotoserver kann dadurch zuerst die Datenbank und den Vektorspeicher von Dify ausbremsen. CPU-Konkurrenz wirkt sich genauso aus: Eine Jellyfin-Bibliothek im Stil einer Videothek der 90er benötigt beim reinen Durchsuchen von Vorschaubildern fast keine Ressourcen. Sobald jedoch jemand eine Transkodierung startet, müssen die Worker-Warteschlangen von Dify hinter diesem Prozess warten. Der Vorteil ist, dass die Anzahl der Dify-Container unabhängig von der Zahl der darauf erstellten Anwendungen konstant bleibt. Das führt zu einer besser vorhersehbaren Kostenentwicklung als bei OpenBot, bei dem jeder KI-Mitarbeiter seinen eigenen Container und seinen eigenen Browser erhält und jeder neue Mitarbeiter den erforderlichen Speicher erneut erhöht.

Da Dify Ihre Model-API-Keys und häufig auch private Dokumente enthält, die Sie für Retrieval geladen haben, sollten Sie den Server ab der ersten Minute als vertraulich behandeln. Dieser Leitfaden installiert Dify und härtet es anschließend so ab, wie Sie jeden Dienst absichern würden, der Geheimnisse speichert.

Voraussetzungen

Sie benötigen einen VPS mit Ubuntu 24.04, mindestens 4 GiB RAM und zwei CPU-Kernen, Docker mit installiertem Docker-Compose-Plugin (Dify erfordert Compose 2.24.0 oder höher) sowie einen Benutzer mit sudo oder der Mitgliedschaft in der Gruppe docker. Der folgende Klonbefehl verwendet außerdem git, curl und jq. Wenn Docker für Sie neu ist, behandelt die Grundlagen von Docker Compose auf einem VPS die Installation und die grundlegenden Befehle, die in dieser Anleitung vorausgesetzt werden. Ein auf den Server verweisender Domainname ist sinnvoll, da Sie TLS vor Dify verwenden sollten, statt Dify über eine nicht geschützte IP-Adresse bereitzustellen.

Schritt 1: Dify und seine Compose-Dateien abrufen

Dify verwaltet seine Docker-Konfiguration im Haupt-Repository. Klonen Sie die aktuelle Version, nicht den Entwicklungs-Branch, und wechseln Sie in das Docker-Verzeichnis:

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

Wenn das Klonen mit dem Fehler „Remote branch null“ fehlschlägt, hat die GitHub-API-Abfrage kein Ergebnis geliefert. Wählen Sie auf der Releases-Seite eine Version aus und übergeben Sie sie manuell an --branch.

Die Datei .env enthält die zentrale Konfiguration. Lesen Sie sie, bevor Sie etwas starten. Zuerst sind die Werte relevant, die Passwörter und Geheimnisse festlegen: SECRET_KEY, das Postgres-Passwort und das Redis-Passwort. SECRET_KEY ist standardmäßig leer. Wenn Sie diesen Wert unverändert lassen, generiert Dify einen Schlüssel und speichert ihn in seinem Speicherverzeichnis. Bei den Passwörtern ist die Situation anders: Die Beispieldatei verwendet für Postgres und Redis denselben difyai123456 sowie fest vorgegebene, öffentlich bekannte Schlüssel für die Code-Sandbox, den Plugin-Daemon und Weaviate. Wenn Sie diese Standardwerte beibehalten, ist das der häufigste Grund dafür, dass eine selbst gehostete Dify-Installation kompromittiert wird. Wenn Sie lieber einen eigenen geheimen Schlüssel festlegen möchten, generieren Sie einen:

openssl rand -base64 42

Fügen Sie ihn in SECRET_KEY ein und legen Sie für jedes Passwort- und Schlüsselfeld in der Datei einen starken, eindeutigen Wert fest. Das Redis-Passwort steht auch in CELERY_BROKER_URL. Ändern Sie es dort ebenfalls, da der Worker andernfalls Redis nicht erreichen kann.

Schritt 2: Starten

Starten Sie den Stack:

docker compose up -d

Beim ersten Start werden mehrere Images abgerufen und die Datenbank initialisiert. Warten Sie daher etwa eine Minute. Prüfen Sie, ob die Container fehlerfrei laufen:

docker compose ps

Jeder dauerhaft laufende Dienst sollte running lesen. Der einmalige Berechtigungs-Task wird beendet, sobald er seine Aufgabe erledigt hat. Dify stellt seine Weboberfläche standardmäßig über einen enthaltenen nginx-Container auf Port 80 bereit. Beim ersten Aufruf von http://YOUR_SERVER/install erstellen Sie das Administratorkonto. Führen Sie das sofort aus, bevor ein anderer Zugriff auf den Port möglich ist. Solange dieses Konto nicht existiert, kann jeder, der die Seite lädt, es beanspruchen und Ihre Instanz übernehmen.

Schritt 3: Veröffentlichen Sie es nicht direkt. Schalten Sie TLS und eine Firewall davor

Hier enden die meisten Schnellinstallationen, und hier beginnen die meisten Sicherheitsvorfälle. Der eigene nginx von Dify lauscht unverschlüsselt auf Port 80 an jeder Schnittstelle und veröffentlicht außerdem Port 443. Ihre Admin-Anmeldedaten und Modellschlüssel sollen nicht über unverschlüsseltes HTTP übertragen werden. Ebenso sollen die internen Dienste nicht von außen erreichbar sein.

Sichern Sie den Server mit einer standardmäßig sperrenden Firewall ab, die nur SSH- und Webverkehr zulässt:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Beachten Sie, dass eine Firewall, die nur IPv4 abdeckt, dieselben Ports unter IPv6 offen lassen kann. Diese IPv6-Firewall-Lücke führt bei vielen Self-Hosting-Installationen zu Problemen. Prüfen Sie, ob beide Protokollstacks gefiltert werden. Beachten Sie außerdem, dass von Docker veröffentlichte Ports durch die eigenen Firewall-Regeln von Docker verwaltet werden, nicht durch die Regeln von ufw. Der Standard-Stack veröffentlicht den Debugging-Port des Plugin-Daemons, 5003, an jeder Schnittstelle. Setzen Sie EXPOSE_PLUGIN_DEBUGGING_PORT in .env auf 127.0.0.1:5003, sofern Sie Plugins nicht tatsächlich von einem anderen Rechner aus debuggen möchten.

Für TLS ist es am saubersten, Dify's Webport an loopback zu binden und davor einen Reverse Proxy mit einem Let's-Encrypt-Zertifikat zu betreiben. Im öffentlichen Internet ist dann nur der Proxy über HTTPS erreichbar. Mit Dify's .env können Sie den veröffentlichten Port ändern. Setzen Sie ihn so, dass er an 127.0.0.1 gebunden wird, und leiten Sie Ihren Proxy dorthin. Gehen Sie bei EXPOSE_NGINX_SSL_PORT genauso vor, weil Dify's nginx standardmäßig den Host-Port 443 belegt und Ihr Proxy ihn benötigt. Die Hinweise zur Absicherung von Agents aus einen AI-Agent sicher auf einem VPS betreiben gelten auch hier: Halten Sie die Komponenten auf loopback, veröffentlichen Sie nur zwingend erforderliche Dienste, und lassen Sie nur einen gehärteten Zugangspunkt TLS bereitstellen. Wenn eine Oberfläche ausschließlich für Sie bestimmt ist und überhaupt kein Zertifikat benötigt, überspringen Sie den Proxy und greifen Sie über einen SSH-Tunnel darauf zu. So bindet den Open-Kritt-Sicherheitsscanner selbst hosten sein Dashboard an loopback und leitet es stattdessen zu Ihrem Laptop weiter, anstatt es zu veröffentlichen. Wenn ein ganzes Team Dify benötigt, das öffentliche Internet aber nicht, lässt sich dieses Prinzip mit einem Overlay-Netzwerk über einen einzelnen Laptop hinaus skalieren: das private Subnetz des Servers für Ihr Tailnet bekanntgeben ermöglicht jedem zugelassenen Gerät, den Builder über eine private Adresse zu erreichen, während die Firewall bis auf SSH für alles geschlossen bleibt. Wenn Sie diesen Server über einen Coding-Agent statt manuell verwalten, legen Sie fest, wie viel er unbeaufsichtigt ausführen darf, bevor Sie ihm die Schlüssel übergeben. Denn der Berechtigungsmodus, in dem Sie Claude Code belassen bestimmt, ob das System vor dem Umschreiben von .env oder dem Neustart des Stacks nachfragt. Wenn in einer Sitzung Container-Logs verfolgt werden, während eine andere Sitzung die Proxy-Konfiguration bearbeitet, können diese beiden Sitzungen auf demselben Server Text austauschen. Dadurch müssen Sie die Ausgabe beim Neustart des Stacks nicht jedes Mal zwischen Terminals kopieren.

Schritt 4: Halten Sie das System aktuell

Dify entwickelt sich schnell weiter, und Updates enthalten Sicherheitskorrekturen. Da Sie einen Release-Tag geklont haben, bedeutet eine Aktualisierung, dass Sie den nächsten Tag auschecken, statt einen Branch zu aktualisieren. Sichern Sie zuerst die Datenbank. Führen Sie anschließend im Verzeichnis docker Folgendes aus:

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

Datenbankmigrationen werden beim Start automatisch ausgeführt. Einige davon können nicht rückgängig gemacht werden. Deshalb wird die Sicherung zuerst erstellt. Lesen Sie vor jedem Upgrade die Release Notes, nicht nur vor größeren Upgrades. Dify weist darauf hin, dass sich die Upgrade-Schritte zwischen den Releases unterscheiden. In den Release Notes zu 1.17.1 (September 2026) wird beispielsweise empfohlen, dass Benutzer der gebündelten Weaviate-Instanz mit vorhandenen Daten nicht direkt auf diese Version aktualisieren. Stattdessen sollen sie jedes Minor Release nacheinander installieren. Dify ändert außerdem das .env-Schema zwischen den Releases. Vergleichen Sie daher nach dem Auschecken eines neuen Tags .env.example mit Ihrem .env und übertragen Sie Ihre Änderungen. Eine neue Variable, die Sie nicht gesetzt haben, kann sonst verhindern, dass ein Container startet.

Schritt 5: Sichern Sie, was sich nicht neu erzeugen lässt

Zwei Dinge auf einem Dify-Server sind nicht ersetzbar: die Postgres-Datenbank mit Ihren Apps, Benutzern und Einstellungen sowie das Volume mit den hochgeladenen Dokumenten und dem Vektorindex. Beide liegen in Docker-Volumes im Verzeichnis docker. Erstellen Sie nach einem Zeitplan Snapshots und kopieren Sie diese vom Server weg. Die Snapshots enthalten jeden Model-Key und jedes hochgeladene Dokument in einer einzigen Datei. Verschlüsseln Sie sie daher, bevor sie den Server verlassen. Der Grund ist derselbe wie bei einem Vaultwarden-Backup, das sich als Schwachstelle eines ansonsten sicheren Passwortservers erweist. Einen Model-API-Key können Sie neu ausstellen lassen. Die Anwendung, in die Sie eine Woche Arbeit investiert haben, nicht. Dieselbe Überlegung gilt für jeden Agenten, dessen Zustand die Maschine überdauern muss, auf der er ausgeführt wird: KiroCrew als permanent laufenden Container weiterzubetreiben bedeutet, den Speicher und die Zeitpläne zu sichern, die andernfalls beim nächsten Reboot verschwinden würden.

Wenn die Agenten, die Sie hier erstellen, über Ihre eigenen Datensätze hinaus auf das Live-Web zugreifen und darin suchen sollen, hält die Anbindung an eine selbst gehostete SearXNG-Instanz den Abfragestrom auf Hardware, die Sie kontrollieren. Lesen Sie sich jedoch zunächst in die Angriffsfläche durch Prompt Injection ein, die dadurch entsteht. Für einen autonomeren Agenten, der Code ausführt, siehe Self-Hosting von Agent Zero. Den eigenen AI-Agenten auf einem VPS zu erstellen behandelt die Grundlagen, auf denen alle diese Lösungen aufbauen.

FAQ

Welche Systemanforderungen gelten für das Self-Hosting von Dify?

Dify nennt mindestens 4 GiB RAM und zwei CPU-Kerne sowie Docker Compose 2.24.0 oder höher. Diese Mindestanforderungen ergeben sich aus der Größe des Standard-Stacks: 15 dauerhaft laufende Container und eine einmalige Initialisierungsaufgabe, Stand Oktober 2026. Planen Sie zusätzlichen Speicherplatz für hochgeladene Dokumente und den Vektorindex ein. Wenn auf dem Server weitere Dienste laufen, benötigen Sie außerdem mehr Arbeitsspeicher.

Ist es sicher, Dify direkt über Port 80 erreichbar zu machen?

Nein. Der mitgelieferte Webserver von Dify lauscht auf unverschlüsseltem HTTP und stellt sowohl die Administrationsanmeldung als auch Ihre Model-API-Schlüssel bereit. Schalten Sie einen Reverse Proxy mit einem Let’s-Encrypt-Zertifikat davor, binden Sie den Port von Dify an loopback und lassen Sie nur den HTTPS-Proxy aus dem Internet erreichbar sein. Ergänzen Sie dies durch eine Firewall mit standardmäßig blockiertem eingehendem Verkehr für IPv4 und IPv6.

Wie aktualisiere ich ein selbst gehostetes Dify?

Sichern Sie zunächst die Datenbank. Führen Sie dann im Verzeichnis docker die Befehle docker compose down, git fetch --tags, git checkout mit dem neuen Release-Tag, docker compose pull und docker compose up -d aus. Lesen Sie vorher die Release Notes, da sich die Aktualisierungsschritte zwischen Releases unterscheiden. Migrationen können nicht rückgängig gemacht werden. Außerdem fügt Dify gelegentlich neue .env-Variablen hinzu. Fehlt eine davon, kann ein Container möglicherweise nicht starten.

Was sollte ich nach der Installation von Dify als Erstes tun?

Rufen Sie /install auf und erstellen Sie sofort das Administratorkonto. Solange dieses Konto nicht existiert, kann jeder, der die Seite erreicht, das Konto übernehmen. Richten Sie es ein, sobald die Container betriebsbereit sind, und bevor Sie die Firewall für das Internet öffnen.