Dify einrichten: 12 Schritte, 139.000 Stars [2026]

Wer heute eine eigene KI-Anwendung bauen will, landet fast zwangsläufig bei der Frage, wie viel Code dafür wirklich nötig ist. Dify beantwortet das mit einer visuellen Oberfläche, auf der sich Chatbots, Agenten und RAG-Anwendungen per Drag-and-drop zusammenklicken lassen, ohne dass ein eigenes Backend geschrieben werden muss. Das Projekt von langgenius ist inzwischen eines der meistgenutzten Open-Source-Werkzeuge für KI-Anwendungsentwicklung und zählt auf GitHub rund 139.000 Sterne, wie eine unabhängige Marktanalyse aus dem Jahr 2026 zeigt.

Der Reiz von Dify liegt darin, dass es sich komplett selbst betreiben lässt. Statt Chatverläufe, Dokumente und API-Schlüssel bei einem gehosteten Dienst abzulegen, läuft der komplette Stack, Datenbank, Vektor-Speicher und Weboberfläche inklusive, auf dem eigenen Server. Das macht die Plattform besonders für Unternehmen im DACH-Raum interessant, die aus Datenschutzgründen keine Kundendaten an fremde Rechenzentren übergeben wollen.

Diese Anleitung führt in zwölf Schritten von einem leeren Server bis zu einer produktiv nutzbaren Dify-Instanz mit HTTPS, angebundenem Modell-Anbieter und einem ersten funktionierenden KI-Workflow. Eingerechnet Server-Vorbereitung, Docker-Installation und erste Tests dauert das komplette Setup je nach Erfahrung und Internetgeschwindigkeit zwischen 45 und 90 Minuten. Am Ende steht ein vollständiges Projekt: ein Support-Bot, der eigene Dokumente durchsucht und über eine öffentliche API ansprechbar ist.

Wichtig vorab: Diese Anleitung richtet sich an Entwickler und IT-Verantwortliche mit grundlegenden Linux- und Docker-Kenntnissen. Wer noch nie ein Terminal geöffnet hat, sollte zuerst mit den einzelnen Befehlen in einer Testumgebung experimentieren, bevor ein produktiver Server aufgesetzt wird. Alle Befehle in diesem Artikel sind für Debian- und Ubuntu-Systeme geschrieben, funktionieren mit kleinen Anpassungen aber auch auf den meisten anderen gängigen Linux-Distributionen.

Was ist Dify und wofür wird die Plattform eingesetzt?

Dify ist eine Open-Source-Plattform zum Erstellen und Betreiben von KI-Anwendungen, von einfachen Chatbots bis zu mehrstufigen Agenten-Workflows. Der Code liegt öffentlich auf GitHub und steht unter einer modifizierten Apache-2.0-Lizenz, was bedeutet: Der Quelltext ist frei einsehbar und nutzbar, mit ein paar zusätzlichen Bedingungen für kommerzielle Weiterverbreitung unter eigenem Markennamen.

Technisch besteht Dify aus mehreren Diensten, die zusammen als Docker-Compose-Stack laufen: einer API-Komponente, Hintergrund-Workern für lange Aufgaben, einer PostgreSQL-Datenbank, Redis für Caching und Warteschlangen sowie einem Vektor-Speicher für die Dokumentensuche. Seit Version 1.0.0 im Februar 2025 wurden Modelle und Werkzeuge in ein eigenes Plugin-System ausgelagert, das über einen separaten Plugin-Daemon verwaltet wird. Das hat den Effekt, dass neue Modell-Anbieter oder Werkzeuge eingebunden werden können, ohne den Kern der Anwendung zu verändern.

Für Entwickler bedeutet das in der Praxis: Ein Chatbot, der auf eigene PDF-Dokumente zugreift, lässt sich in Dify über eine grafische Oberfläche zusammenstellen, statt Retrieval, Prompt-Engineering und API-Anbindung von Hand zu programmieren. Wer tiefer einsteigen will, kann trotzdem eigenen Code über Custom Tools oder die REST-API einbinden. Diese Mischung aus No-Code-Oberfläche und Erweiterbarkeit erklärt einen Großteil der Popularität des Projekts.

Dify im Vergleich zu LangChain, Flowise und n8n

Dify konkurriert nicht direkt mit LangChain, sondern setzt eine Ebene höher an. Während LangChain ein Entwicklungs-Framework für Python- oder JavaScript-Code ist, liefert Dify eine fertige Anwendung mit Oberfläche, Nutzerverwaltung und Deployment-Struktur. Flowise ist Dify konzeptionell am nächsten, weil beide auf visuelle Workflow-Editoren setzen. n8n wiederum kommt ursprünglich aus der klassischen Automatisierung und hat KI-Funktionen erst nachträglich integriert, deckt dafür aber mehr generische Integrationen außerhalb des KI-Bereichs ab.

Plattform	Ansatz	Stärke	Typischer Einsatz
Dify	Fertige App-Plattform mit visuellem Editor	RAG, Agenten, Modell-Verwaltung aus einer Hand	KI-Anwendungen mit Wissensbasis und API-Anbindung
LangChain	Code-Framework (Python/JS)	Maximale Kontrolle und Flexibilität	Individuelle Anwendungen mit eigenem Backend
Flowise	Visueller Editor auf LangChain-Basis	Schneller Einstieg für LangChain-Konzepte	Prototypen und einfache Chat-Flows
n8n	Allzweck-Automatisierung mit KI-Nodes	Breite Integration in bestehende Systeme	Workflow-Automatisierung, KI als ein Baustein von vielen

Wer bereits eine n8n-Instanz für Automatisierung betreibt, muss Dify nicht zwingend zusätzlich einführen. Sobald aber eine Wissensbasis mit mehreren hundert Dokumenten, feingranulare Zugriffsrechte für Teams oder ein dediziertes Agenten-Framework gebraucht werden, spielt Dify seine Stärken aus.

In der Praxis tauchen drei Einsatzszenarien besonders häufig auf. Das erste ist der interne Support-Bot, der Mitarbeitern oder Kunden Fragen anhand von Handbüchern und FAQ-Dokumenten beantwortet, ohne dass jede Anfrage bei einem menschlichen Sachbearbeiter landet. Das zweite ist ein mehrstufiger Agent, der eigenständig Werkzeuge aufruft, etwa eine Datenbankabfrage startet oder eine externe API anspricht, bevor er eine Antwort formuliert. Das dritte ist die Rolle als zentrale Schaltstelle für mehrere Modell-Anbieter: Statt jede Anwendung einzeln an OpenAI, Claude oder ein lokales Modell anzubinden, läuft der gesamte Modell-Zugriff über eine einzige Dify-Instanz, was Wechsel zwischen Anbietern erheblich vereinfacht.

Ergänzt wird der Kern der Plattform durch einen Marktplatz für Plugins, über den sich zusätzliche Werkzeuge, Suchanbieter oder spezialisierte Modell-Integrationen nachrüsten lassen, ohne den eigenen Server-Code anzufassen. Für die tägliche Arbeit bedeutet das: Ein neues Werkzeug, etwa eine Websuche oder eine Wetter-API, lässt sich in wenigen Klicks aktivieren, statt zuerst eine eigene Schnittstelle dafür zu programmieren.

Voraussetzungen: Diese Versionen und Ressourcen brauchst du

Bevor der erste Befehl eingegeben wird, lohnt sich ein Blick auf die tatsächlichen Mindestanforderungen. Sie fallen kleiner aus, als viele erwarten, wachsen aber mit der Zahl der Dokumente in der Wissensbasis.

Komponente	Minimum	Empfohlen
vCPU	2	2-4
Arbeitsspeicher	2 GB	4-8 GB
Speicherplatz	20 GB SSD/NVMe	40 GB+ NVMe, abhängig vom Dokumentenvolumen
Docker Compose	v2.24.0 oder neuer	jeweils aktuelle stabile Version
Betriebssystem	Debian 12 oder Ubuntu 24.04	gleiche Distribution, aktuell gepatcht
Offene Ports	80 (HTTP)	80 und 443 (HTTPS) hinter Reverse Proxy

Die Speicherlast entsteht vor allem durch Datenbank und Vektor-Index, nicht durch Dify selbst. Wer nur einen kleinen Chatbot mit wenigen Dokumenten testet, kommt mit 2 GB RAM aus. Sobald mehrere Nutzer gleichzeitig arbeiten oder eine Wissensbasis mit hunderten Dateien indexiert wird, steigt der Bedarf schnell auf 4 bis 8 GB. Ein günstiger VPS mit vier vCPUs und 8 GB RAM, wie ihn mehrere Hosting-Anbieter für rund 15 bis 25 Euro im Monat anbieten, reicht für die meisten kleinen bis mittleren Teams aus.

Zusätzlich zu Docker Compose brauchst du einen SSH-Zugang mit Root- oder Sudo-Rechten sowie idealerweise eine eigene Domain, die per DNS-A-Record auf den Server zeigt. Ohne eigene Domain lässt sich Dify zwar auch über die IP-Adresse betreiben, ein gültiges TLS-Zertifikat für HTTPS setzt aber einen Domainnamen voraus.

Schritt 1: Server vorbereiten und Firewall einrichten

Zuerst werden die Systempakete aktualisiert und eine restriktive Firewall eingerichtet, bevor überhaupt ein Container läuft. Das reduziert die Angriffsfläche von Anfang an, statt sie nachträglich zu schließen.

apt update && apt upgrade -y
apt install -y ufw curl git
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Wichtig an dieser Stelle: Nur SSH, HTTP und HTTPS werden erlaubt. Der Port, auf dem Dify selbst intern lauscht, bleibt bewusst geschlossen und wird später nur über den Reverse Proxy erreichbar gemacht. Wer diesen Schritt überspringt und Dify direkt auf Port 80 exponiert, ohne TLS, überträgt Admin-Login und Modell-API-Schlüssel im Klartext über das Netz.

Schritt 2: Docker und Docker Compose installieren

Dify wird offiziell als Docker-Compose-Stack ausgeliefert. Die schnellste Installationsmethode unter Debian oder Ubuntu ist das offizielle Convenience-Skript von Docker:

curl -fsSL https://get.docker.com | sh
usermod -aG docker $USER
newgrp docker
docker --version
docker compose version

Das Skript installiert Docker Engine inklusive dem Compose-Plugin in einem Rutsch. Der zweite Befehl fügt den aktuellen Benutzer der Docker-Gruppe hinzu, damit Container-Befehle nicht bei jedem Aufruf mit sudo eingeleitet werden müssen. Die letzten beiden Zeilen prüfen, ob beide Komponenten korrekt installiert sind. Die Ausgabe sollte etwa so aussehen:

Docker version 27.x.x, build xxxxxxx
Docker Compose version v2.29.x

Zeigt docker compose version stattdessen einen Fehler wie “docker: ‘compose’ is not a docker command”, fehlt das Compose-Plugin. Das passiert häufig auf älteren Systemen, auf denen Docker über die Distributions-Paketquelle statt über das offizielle Skript installiert wurde.

Schritt 3: Dify-Repository klonen

Als Nächstes wird das Repository heruntergeladen. Statt einen festen Versions-Tag im Code zu verankern, der schnell veraltet, lohnt es sich, den jeweils aktuellen Release automatisch über die GitHub-API zu ermitteln und direkt auszuchecken:

LATEST_TAG=$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | grep '"tag_name":' | cut -d '"' -f4)
git clone --branch "$LATEST_TAG" --depth 1 https://github.com/langgenius/dify.git
cd dify/docker

Der Vorteil dieser Methode: Die Installation zieht immer die neueste veröffentlichte Version, ohne dass eine Anleitung mit einer festen Versionsnummer nach wenigen Monaten veraltet. Wer stattdessen bewusst eine ältere, getestete Version einsetzen will, ersetzt $LATEST_TAG einfach durch den gewünschten Tag-Namen aus der GitHub-Releases-Übersicht.

Schritt 4: Umgebungsvariablen in der .env-Datei konfigurieren

Im Verzeichnis dify/docker liegt eine Vorlagen-Datei, aus der die eigentliche Konfiguration erzeugt wird:

cp .env.example .env
nano .env

In der Datei sind vor allem drei Werte vor dem ersten Start relevant: SECRET_KEY für die Verschlüsselung von Sitzungsdaten, APP_WEB_URL beziehungsweise CONSOLE_WEB_URL für die spätere öffentliche Domain, und die Datenbank-Zugangsdaten, falls eine externe PostgreSQL-Instanz statt der mitgelieferten genutzt werden soll. Für den SECRET_KEY generierst du einen zufälligen Wert direkt in der Kommandozeile:

openssl rand -base64 42

Der ausgegebene String wird in der .env-Datei als Wert für SECRET_KEY eingetragen. Wer diesen Schritt überspringt und den mitgelieferten Beispielwert unverändert lässt, riskiert, dass Sitzungscookies mit einem öffentlich bekannten Schlüssel signiert werden.

Schritt 5: Den Dify-Stack mit Docker Compose starten

Ist die Konfiguration gesetzt, startet ein einziger Befehl den kompletten Stack im Hintergrund:

docker compose up -d

Beim ersten Start lädt Docker sämtliche Images herunter, was je nach Internetverbindung zwischen zwei und zehn Minuten dauert. Die Ausgabe listet danach alle gestarteten Container einzeln auf, etwa so:

 ✔ Container docker-redis-1      Started
 ✔ Container docker-db-1         Started
 ✔ Container docker-sandbox-1    Started
 ✔ Container docker-weaviate-1   Started
 ✔ Container docker-api-1        Started
 ✔ Container docker-worker-1     Started
 ✔ Container docker-web-1        Started
 ✔ Container docker-nginx-1      Started

Acht bis zehn Container sind für ein Basis-Setup normal. Fehlt einer davon in der Liste oder bricht der Befehl vorher ab, deutet das meist auf einen Port-Konflikt oder eine fehlende Variable in der .env-Datei hin, dazu mehr im Troubleshooting-Teil weiter unten.

Schritt 6: Status prüfen und Logs kontrollieren

Nach dem Start lohnt sich eine kurze Kontrolle, ob wirklich alle Dienste stabil laufen und nicht nur kurzzeitig gestartet wurden, um dann wieder abzustürzen:

docker compose ps
docker compose logs -f api --tail=50

In der Spalte STATUS von docker compose ps sollte bei jedem Container Up stehen, im Idealfall ergänzt um (healthy) bei den Diensten mit Healthcheck. Taucht stattdessen Restarting auf, startet der betroffene Container in einer Schleife neu, meist weil eine Abhängigkeit wie die Datenbank noch nicht bereit war oder eine Pflichtvariable in der .env-Datei fehlt. Der zweite Befehl zeigt die letzten 50 Log-Zeilen der API-Komponente live an und hilft, die genaue Fehlermeldung zu finden.

Schritt 7: Admin-Konto im Setup-Assistenten anlegen

Sobald alle Container laufen, ist die Installation über http://DEINE-SERVER-IP/install erreichbar. Dort wird beim ersten Aufruf E-Mail-Adresse, Benutzername und Passwort für das erste Admin-Konto festgelegt. Dieser Schritt sollte unmittelbar nach dem Start erfolgen und nicht auf später verschoben werden: Bis das Admin-Konto angelegt ist, kann theoretisch jeder, der die Seite erreicht, sich das erste Konto mit vollen Rechten sichern.

Aus diesem Grund ist die Reihenfolge in dieser Anleitung bewusst gewählt: Firewall zuerst, dann der Stack-Start, und die Admin-Einrichtung, bevor überhaupt über den späteren Reverse Proxy von außen zugegriffen wird. Wer testweise Port 80 direkt auf den Container weiterleitet, sollte die Installationsseite in den ersten Minuten nach dem Start aufrufen, nicht erst am nächsten Tag.

Nach der Anmeldung mit dem frisch angelegten Konto lassen sich unter dem Menüpunkt Mitglieder weitere Teammitglieder per E-Mail-Einladung hinzufügen. Jedes eingeladene Konto erhält eine von mehreren abgestuften Rollen, von reinen Betrachtern über Editoren, die Anwendungen bearbeiten dürfen, bis zu weiteren Admin-Konten mit vollem Zugriff auf Einstellungen und Abrechnung. Für Teams, die Dify produktiv einsetzen, lohnt es sich, von Anfang an nicht jedem Mitglied Admin-Rechte zu geben, sondern die Rechtevergabe an der tatsächlichen Aufgabe auszurichten, etwa Editor-Rechte für alle, die Workflows bauen, und Admin-Rechte nur für die Person, die auch den Server verwaltet.

Schritt 8: Reverse Proxy und HTTPS mit Nginx und Let’s Encrypt einrichten

Für den produktiven Betrieb gehört ein TLS-Zertifikat vor jede Installation, die über das offene Internet erreichbar ist. Die gängige Kombination ist Nginx als Reverse Proxy vor dem Dify-Stack, kombiniert mit einem kostenlosen Let’s-Encrypt-Zertifikat:

apt install -y nginx certbot python3-certbot-nginx

cat > /etc/nginx/sites-available/dify <<'EOF'
server {
    listen 80;
    server_name dify.deinedomain.de;

    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
EOF

ln -s /etc/nginx/sites-available/dify /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
certbot --nginx -d dify.deinedomain.de

Certbot verändert die Nginx-Konfiguration danach automatisch so, dass Anfragen auf Port 80 auf HTTPS umgeleitet werden, und richtet die automatische Zertifikatserneuerung per Cronjob ein. Wichtig: In der docker-compose.yaml sollte der interne Nginx-Container von Dify nicht direkt an die öffentliche IP gebunden werden. Stattdessen bindest du den Port in der Compose-Datei auf 127.0.0.1:80, damit ausschließlich der System-Nginx mit gültigem Zertifikat von außen erreichbar ist.

Schritt 9: Modell-Provider verbinden: Ollama, OpenAI, Claude, Gemini und DeepSeek

Dify selbst bringt keine eigenen Sprachmodelle mit, sondern verbindet sich mit externen Anbietern. In der Weboberfläche geschieht das unter Einstellungen und Modell-Anbieter, wo je nach gewünschtem Anbieter ein API-Schlüssel hinterlegt wird. Laut der offiziellen Model-Provider-Dokumentation unterstützt Dify unter anderem OpenAI, Anthropic (Claude), Google Gemini, DeepSeek und lokale Modelle über Ollama.

Für Cloud-Anbieter wie OpenAI oder Claude reicht das Einfügen des API-Schlüssels aus der jeweiligen Entwickler-Konsole. Für ein lokales Setup mit Ollama, das auf demselben Server oder im selben Netzwerk läuft, wird stattdessen die Basis-URL http://host.docker.internal:11434 eingetragen, damit der Dify-Container die auf dem Host laufende Ollama-Instanz erreicht, statt sie im eigenen, isolierten Container-Netzwerk zu suchen.

Ein Detail, das in der Praxis häufig übersehen wird: Für jede Anwendung in Dify lässt sich ein eigenes Standardmodell festlegen. Das erlaubt es, günstigere oder lokale Modelle für einfache Aufgaben wie Zusammenfassungen zu nutzen und teurere Cloud-Modelle gezielt dort einzusetzen, wo es auf höhere Qualität ankommt, etwa bei komplexen mehrstufigen Agenten-Workflows.

Schritt 10: Wissensbasis für Retrieval-Augmented Generation anlegen

Der nächste Schritt ist der eigentliche Kern vieler Dify-Projekte: eine Wissensbasis, gegen die das Modell später Fragen beantwortet, statt nur aus seinem Trainingswissen zu antworten. Im Menüpunkt Wissen wird ein neuer Datensatz angelegt, in den PDF-, Word- oder Markdown-Dateien hochgeladen werden.

Dify übernimmt beim Hochladen automatisch das Zerlegen der Dokumente in kleinere Textabschnitte, die Erzeugung von Embeddings über das gewählte Modell und die Ablage im Vektor-Speicher. In den erweiterten Einstellungen lässt sich festlegen, wie groß diese Textabschnitte ausfallen und wie viel Überlappung zwischen ihnen besteht. Für die meisten Anwendungsfälle mit Fließtext-Dokumenten funktionieren die Standardwerte bereits gut, bei stark strukturierten Dokumenten wie Tabellen oder FAQ-Listen lohnt sich dagegen eine manuelle Anpassung, damit zusammengehörige Informationen nicht mitten im Abschnitt zerschnitten werden.

Nach dem Indexieren lässt sich die Trefferqualität direkt im integrierten Retrieval-Test überprüfen: Eine Testfrage wird eingegeben, und Dify zeigt an, welche Textabschnitte aus der Wissensbasis dafür herangezogen würden, noch bevor überhaupt ein Chatbot damit verbunden ist.

Eigene Werkzeuge und Code-Knoten in den Workflow einbauen

Reine Wissensbasis-Antworten reichen für viele Projekte nicht aus, sobald der Chatbot auch auf Live-Daten zugreifen soll, etwa den aktuellen Bestellstatus aus einem internen System. Für solche Fälle bringt der Workflow-Editor einen Code-Knoten mit, in dem sich kleine Python- oder JavaScript-Funktionen direkt im Browser hinterlegen lassen, ohne eine externe Codebasis zu pflegen.

def main(order_id: str) -> dict:
    import requests
    response = requests.get(
        f"https://interne-api.deinefirma.de/orders/{order_id}",
        timeout=5,
    )
    if response.status_code != 200:
        return {"status": "nicht gefunden"}
    data = response.json()
    return {"status": data.get("status", "unbekannt")}

Der Code-Knoten nimmt die vom vorherigen Knoten übergebenen Variablen entgegen, in diesem Fall eine erkannte Bestellnummer, und liefert ein strukturiertes Ergebnis an den nächsten Schritt im Workflow zurück. Alternativ lässt sich dieselbe Logik auch ohne eigenen Code über einen HTTP-Request-Knoten abbilden, der eine externe API direkt aus der Oberfläche heraus aufruft. Für einfache GET- oder POST-Anfragen ohne komplexe Vorverarbeitung ist der HTTP-Knoten meist die schnellere Wahl, während der Code-Knoten seine Stärken ausspielt, sobald mehrere Werte kombiniert oder Antworten vor der Weitergabe umgeformt werden müssen.

Wer eine Funktion häufiger in mehreren Anwendungen braucht, kann sie stattdessen als eigenes Custom Tool registrieren. Damit taucht das Werkzeug im selben Auswahlmenü auf wie die eingebauten Tools aus dem Plugin-Marktplatz und lässt sich ohne erneutes Kopieren des Codes in beliebig vielen Workflows wiederverwenden.

Schritt 11: Ersten KI-Workflow bauen – ein komplettes Support-Bot-Projekt

Mit angebundenem Modell und gefüllter Wissensbasis lässt sich jetzt das eigentliche Projekt zusammensetzen: ein Support-Bot, der Kundenfragen anhand der eigenen Dokumentation beantwortet und über eine API in eine bestehende Website eingebunden werden kann.

Im Menüpunkt Studio wird eine neue Anwendung vom Typ Chatflow erstellt. Der visuelle Editor zeigt danach einen Startknoten, der die Nutzereingabe entgegennimmt. Von dort wird ein Knowledge-Retrieval-Knoten angehängt, der die zuvor angelegte Wissensbasis durchsucht, gefolgt von einem LLM-Knoten, der die gefundenen Textabschnitte zusammen mit der ursprünglichen Frage an das gewählte Modell schickt. Ein Antwort-Knoten am Ende gibt das Ergebnis an den Nutzer zurück. Im Prompt des LLM-Knotens wird festgelegt, dass das Modell ausschließlich auf Basis der gefundenen Textabschnitte antworten soll und bei fehlender Information ehrlich sagen soll, dass es die Antwort nicht kennt, statt zu spekulieren.

Nach dem Testen im integrierten Vorschau-Chat wird die Anwendung über den Button Veröffentlichen live geschaltet. Dify erzeugt dabei automatisch einen API-Endpunkt samt eigenem API-Schlüssel, der sich direkt testen lässt:

curl -X POST 'https://dify.deinedomain.de/v1/chat-messages' \
  -H 'Authorization: Bearer app-DEIN_API_SCHLUESSEL' \
  -H 'Content-Type: application/json' \
  -d '{
    "inputs": {},
    "query": "Wie lange dauert die Lieferung?",
    "response_mode": "blocking",
    "user": "test-nutzer-01"
  }'

Eine erfolgreiche Antwort sieht in gekürzter Form so aus:

{
  "event": "message",
  "answer": "Laut unserer Versandinformation dauert die Standardlieferung 2-4 Werktage.",
  "conversation_id": "8f3a2c91-...",
  "message_id": "b71e04d2-..."
}

Ab diesem Punkt ist das Projekt vollständig: Der Endpunkt lässt sich in ein Website-Widget, eine mobile App oder ein internes Tool einbauen, ohne dass an der Dify-Konfiguration noch etwas geändert werden muss.

Schritt 12: Backup-Strategie und Updates einrichten

Ein selbst gehostetes System ist nur so viel wert wie sein letztes funktionierendes Backup. Die wichtigsten Daten stecken im PostgreSQL-Volume und im Vektor-Speicher. Ein einfaches, planbares Backup-Skript sichert beide Volumes als komprimiertes Archiv:

mkdir -p /backup/dify
docker run --rm \
  -v docker_db_data:/data/db \
  -v docker_weaviate_data:/data/weaviate \
  -v /backup/dify:/backup \
  alpine tar czf /backup/dify-backup-$(date +%F).tar.gz -C / data

Dieser Befehl lässt sich unkompliziert als täglicher Cronjob einrichten, kombiniert mit einer Rotation, die ältere Archive nach einigen Tagen löscht oder auf einen externen Speicher wie S3-kompatiblen Object Storage hochlädt. Für Updates gilt ein ähnlich einfaches Muster: im Verzeichnis dify/docker wird zuerst der neue Code geholt, dann werden die Container-Images aktualisiert und der Stack neu gestartet.

cd dify/docker
git pull
docker compose pull
docker compose up -d

Vor jedem Update lohnt sich ein Blick in die Release-Notes des jeweiligen Tags, da neue Versionen gelegentlich zusätzliche Pflichtvariablen in der .env-Datei erwarten. Fehlt eine davon nach dem Update, verweigert der betroffene Container den Start, statt einfach mit Standardwerten weiterzulaufen.

Produktiv skalieren: mehr Worker, externe Datenbank und Monitoring

Das Standard-Setup aus dieser Anleitung reicht für kleine bis mittlere Teams aus, stößt aber bei wachsender Nutzerzahl an Grenzen. Der erste Engpass zeigt sich meist bei den Hintergrund-Workern, die für lange Aufgaben wie das Indexieren großer Dokumentenmengen zuständig sind. Über Docker Compose lässt sich die Anzahl der Worker-Container gezielt erhöhen:

docker compose up -d --scale worker=3

Mit mehreren Worker-Instanzen lassen sich Indexierungs- und Hintergrundaufgaben parallel abarbeiten, statt sich in einer einzelnen Warteschlange zu stauen. Für sehr große Installationen empfiehlt sich zusätzlich, die mitgelieferte PostgreSQL-Datenbank durch eine extern gemanagte Instanz zu ersetzen, etwa bei einem Cloud-Anbieter mit automatischen Backups und Failover. Die Verbindungsdaten dafür werden in der .env-Datei unter den entsprechenden DB_-Variablen hinterlegt, wodurch der mitgelieferte Datenbank-Container im Compose-Stack komplett entfällt.

Für die Beobachtung des laufenden Betriebs bietet Dify in den höheren Preisstufen der Cloud-Version eine Anbindung an externe Observability-Werkzeuge wie Langfuse oder Langsmith an, mit denen sich Modell-Aufrufe, Latenzen und Tokenverbrauch über alle Anwendungen hinweg auswerten lassen. Wer die Community-Edition selbst hostet, kann dieselben Werkzeuge über die von Dify bereitgestellten Tracing-Schnittstellen ebenfalls einbinden, muss die Integration allerdings selbst konfigurieren, da sie in der Oberfläche der Cloud-Version stärker vorbereitet ist als in der selbst gehosteten Variante.

Bekannte Sicherheitslücken und Härtungsmaßnahmen

Für Dify sind mittlerweile mehrere Sicherheitslücken öffentlich dokumentiert, die bei einem produktiven Einsatz relevant sind. Eine davon, CVE-2025-43862, betraf eine fehlerhafte Rechteprüfung, durch die normale Nutzer App-Konfigurationen verändern konnten, obwohl die entsprechende Oberfläche für sie gar nicht sichtbar war. Der Fehler wurde laut der zugehörigen GitHub-Sicherheitsmeldung in Version 0.6.12 behoben.

Eine zweite Lücke, CVE-2025-58747, betraf die MCP-OAuth-Komponente und erlaubte Cross-Site-Scripting, wenn sich ein Nutzer mit einem von Angreifern kontrollierten MCP-Server verband. Ursache war laut der Sicherheitsmeldung eine fehlende Validierung der Weiterleitungs-URL, die es erlaubte, über ein javascript:-Protokoll Code im Kontext der Anwendung auszuführen. Die Lücke betraf alle Versionen bis einschließlich 1.9.1 und wurde durch eine strikte Protokoll-Prüfung geschlossen.

Beide Fälle zeigen ein wiederkehrendes Muster: Wer eine ältere, ungepatchte Version weiterbetreibt, weil ein Update als lästig empfunden wird, trägt ein konkretes, dokumentiertes Risiko. Für den produktiven Einsatz empfiehlt sich deshalb neben regelmäßigen Updates auch die klassische Härtung: MCP-Verbindungen nur zu vertrauenswürdigen Servern zulassen, Admin-Konten mit starken, einzigartigen Passwörtern versehen, und den Zugriff auf die Konsole zusätzlich per IP-Filter oder VPN einschränken, wenn die Anwendung nicht öffentlich zugänglich sein muss.

Dify Cloud vs. selbst gehostet: Kostenvergleich

Wer sich gegen das Self-Hosting entscheidet, kann Dify auch als gehosteten Cloud-Dienst nutzen. Die Preisstruktur laut der offiziellen Preisseite gliedert sich in vier Stufen.

Plan	Preis	Wesentliche Limits
Sandbox	0 $	200 Nachrichten-Credits insgesamt, 1 Arbeitsbereich, 5 Apps
Professional	59 $/Monat (jährlich rund 49 $/Monat)	5.000 Credits/Monat, 3 Teammitglieder, 50 Apps, 5 GB Wissensspeicher
Team	159 $/Monat (jährlich rund 132 $/Monat)	10.000 Credits/Monat, 50 Teammitglieder, 200 Apps, 20 GB Wissensspeicher
Enterprise	individuell, auf Anfrage	Self-Hosting oder dedizierte Cloud, SOC-2-Bericht, eigenes Branding

Das Self-Hosting über Docker Compose, wie in dieser Anleitung beschrieben, entspricht funktional größtenteils der kostenlosen Community-Version und läuft ohne die genannten Nachrichten- oder Nutzer-Limits der Cloud-Pläne. Die tatsächlichen Kosten bestehen dann nur aus der Server-Miete, üblicherweise 10 bis 30 Euro im Monat für ein kleines bis mittleres Team, plus dem eigenen Zeitaufwand für Updates und Backups. Für einzelne Nutzer oder sehr kleine Projekte kann die kostenlose Sandbox-Stufe der Cloud-Version dagegen schneller einsatzbereit sein, weil Server-Administration komplett entfällt.

Häufige Fehler beim Self-Hosting von Dify

Bei der Recherche zu dieser Anleitung und in zahlreichen Community-Diskussionen tauchen einige Fehler immer wieder auf. Die folgende Liste fasst die häufigsten zusammen, damit sie von vornherein vermieden werden.

Dify direkt auf Port 80 ohne TLS exponieren: Admin-Zugangsdaten und Modell-API-Schlüssel werden dann unverschlüsselt übertragen und lassen sich im lokalen Netz mitlesen.
Admin-Konto nicht sofort nach dem Start anlegen: Solange die /install-Seite offen erreichbar ist, kann sich jeder Erreichende das erste Konto mit vollen Rechten sichern.
Den Standard-SECRET_KEY aus der Beispieldatei übernehmen: Damit lassen sich Sitzungscookies leichter fälschen, weil der Schlüssel öffentlich in der Vorlage steht.
Updates über Monate aufschieben: Wie die dokumentierten CVEs zeigen, wurden konkrete Sicherheitslücken erst in späteren Versionen geschlossen.
Keine Backups des Datenbank- und Vektor-Volumes einrichten: Ohne Sicherung sind bei einem Server-Ausfall sämtliche Konversationen, Nutzerkonten und indexierten Dokumente unwiederbringlich verloren.
Die Firewall erst nach dem ersten Start konfigurieren: In den Minuten zwischen Server-Einrichtung und Firewall-Aktivierung ist die Installation ungeschützt aus dem gesamten Internet erreichbar.

Die meisten dieser Fehler haben eines gemeinsam: Sie entstehen nicht durch Unwissen über Dify selbst, sondern durch das Überspringen grundlegender Server-Hygiene, die bei jedem selbst gehosteten Dienst gilt. Wer die zwölf Schritte dieser Anleitung der Reihe nach abarbeitet, statt einzelne Punkte aus Zeitgründen zu überspringen, umgeht praktisch alle der oben genannten Fallstricke automatisch.

Troubleshooting: Die häufigsten Probleme und Lösungen

Auch bei sorgfältiger Einrichtung tauchen typische Stolpersteine auf. Die folgende Übersicht deckt die Probleme ab, die in der Praxis am häufigsten gemeldet werden.

Container hängt in einer Neustart-Schleife: Meist fehlt eine Pflichtvariable in der .env-Datei oder die Datenbank war beim Start des abhängigen Dienstes noch nicht bereit. docker compose logs -f [dienstname] zeigt die genaue Ursache.
Seite unter der Domain nicht erreichbar, obwohl Container laufen: Häufig zeigt der DNS-A-Record noch nicht auf die richtige IP, oder die Nginx-Konfiguration wurde nach dem Anlegen nicht mit nginx -t && systemctl reload nginx aktiviert.
Certbot bricht mit einem Validierungsfehler ab: Das passiert meist, wenn Port 80 in der Firewall noch nicht freigegeben ist oder ein anderer Dienst den Port bereits belegt.
Ollama-Modell wird in Dify nicht gefunden: Statt localhost muss in der Modell-Konfiguration host.docker.internal als Basis-URL eingetragen werden, da der Dify-Container sonst in seinem eigenen, isolierten Netzwerk sucht.
Dokumenten-Upload in der Wissensbasis schlägt fehl: Oft liegt es an einer zu niedrigen Datei-Größenbeschränkung in der Nginx-Konfiguration, die mit client_max_body_size angehoben werden muss.
API-Anfragen liefern einen 401-Fehler: Der App-spezifische API-Schlüssel unterscheidet sich vom persönlichen Konsolen-Zugang. Beide dürfen nicht verwechselt werden.
Nach einem Update startet ein Container nicht mehr: Ein Blick in die Release-Notes des neuen Tags zeigt meist, welche zusätzliche Variable in der .env-Datei ergänzt werden muss.
Antworten des Chatbots ignorieren die Wissensbasis: Der Knowledge-Retrieval-Knoten im Workflow-Editor ist nicht korrekt mit dem LLM-Knoten verbunden, oder die Wissensbasis wurde der jeweiligen Anwendung nicht zugewiesen.
Server läuft mit hoher CPU-Auslastung im Leerlauf: Häufig läuft im Hintergrund noch ein Indexierungsjob für gerade hochgeladene Dokumente. Der Fortschritt lässt sich im Wissensbasis-Bereich der Oberfläche einsehen.

Lässt sich ein Problem mit keinem der genannten Schritte lösen, hilft in der Regel ein Blick in die GitHub-Discussions des Projekts, wo ähnliche Fehlerbilder häufig bereits von anderen Nutzern gemeldet und gelöst wurden. Wichtig dabei: Beim Posten eines eigenen Problems lohnt es sich, die Ausgabe von docker compose logs und die verwendete Versions-Tag-Nummer direkt mitzuliefern, da die meisten hilfreichen Antworten ohne diese beiden Angaben nur raten können.

Fortgeschrittene Tipps für den produktiven Einsatz

Sobald das Grundsetup läuft, lohnen sich einige zusätzliche Anpassungen. Erstens: Für Teams mit mehreren Abteilungen empfiehlt sich eine getrennte Wissensbasis pro Fachbereich statt eines gemeinsamen Datentopfs. Das verhindert, dass irrelevante Treffer aus anderen Bereichen die Antwortqualität verwässern.

Zweitens: Nutze in produktiven Workflows unterschiedliche Modelle je nach Aufgabe. Ein kleineres, günstiges oder lokal gehostetes Modell reicht oft für einfache Klassifikations- oder Zusammenfassungsschritte innerhalb eines Workflows, während das teurere Cloud-Modell gezielt für den finalen, nutzerseitigen Antwortschritt reserviert bleibt.

Drittens: Aktiviere Rate-Limiting auf Ebene des Reverse Proxys für öffentlich zugängliche API-Endpunkte. Ein einzelner Chatbot-Endpunkt ohne Begrenzung lässt sich sonst leicht missbrauchen, um kostenpflichtige Modell-Aufrufe in großer Zahl auszulösen.

Viertens: Für Workflows mit mehreren Agenten-Schritten lohnt sich der Blick in die integrierten Logs jeder Anwendung. Dort lässt sich pro Konversation nachvollziehen, welcher Knoten wie lange gebraucht hat und wie viele Tokens verbraucht wurden, was bei der Kostenkontrolle und der Fehlersuche gleichermaßen hilft.

Fünftens: Wer mehrere Dify-Umgebungen betreibt, etwa eine für Tests und eine für den produktiven Betrieb, sollte die exportierbaren Workflow-Definitionen nutzen, um Änderungen versioniert zwischen den Umgebungen zu übertragen, statt jede Anpassung manuell in beiden Oberflächen nachzubauen.

Chatflow, Workflow oder Agent: Welcher Anwendungstyp passt zu welchem Projekt

Beim Anlegen einer neuen Anwendung im Studio-Bereich stellt Dify mehrere Grundtypen zur Auswahl, und die Wahl des richtigen Typs entscheidet maßgeblich darüber, wie viel Konfigurationsaufwand später anfällt. Der Chatflow-Typ, wie im Support-Bot-Beispiel dieser Anleitung verwendet, eignet sich für dialogorientierte Anwendungen mit mehreren Verarbeitungsschritten pro Nachricht, etwa Retrieval gefolgt von einer Modell-Antwort. Der einfachere Chatbot-Typ ohne visuellen Workflow-Editor reicht dagegen, wenn nur ein einzelnes Modell mit einer Wissensbasis verbunden werden soll, ohne Verzweigungen oder zusätzliche Werkzeuge.

Der Workflow-Typ eignet sich für Aufgaben ohne fortlaufenden Dialog, etwa die automatische Klassifizierung eingehender Support-Tickets oder die Zusammenfassung hochgeladener Dokumente in einem einzigen Durchlauf. Der Agent-Typ schließlich gibt dem Modell die Kontrolle darüber, welche Werkzeuge es in welcher Reihenfolge aufruft, statt einen festen Ablauf vorzugeben. Das ist mächtiger, aber auch schwerer vorhersehbar: Ein Agent kann bei unklaren Eingaben unerwartete Werkzeugaufrufe auslösen, weshalb sich für die meisten Support- und FAQ-Anwendungsfälle der planbarere Chatflow-Typ besser eignet und der Agent-Modus eher für Aufgaben mit echtem Entscheidungsbedarf reserviert bleiben sollte, etwa das eigenständige Recherchieren mehrerer Datenquellen vor einer Antwort.

Datenschutz und Compliance in der DACH-Region

Ein selbst gehostetes Setup wie das in dieser Anleitung beschriebene löst die Frage, wohin Chatverläufe und Dokumente übertragen werden, ersetzt aber keine vollständige Datenschutz-Folgenabschätzung. Wer Dify im Unternehmenskontext einsetzt, sollte dokumentieren, welche Daten in der Datenbank und im Vektor-Speicher landen, wie lange sie aufbewahrt werden und wer administrativen Zugriff auf den Server hat. Läuft eine Wissensbasis mit personenbezogenen Kundendaten, gelten dieselben Anforderungen wie bei jeder anderen Verarbeitung nach der Datenschutz-Grundverordnung.

Ein praktischer Vorteil bleibt dennoch bestehen: Solange ausschließlich lokale Modelle über Ollama angebunden werden, verlässt keine Anfrage den eigenen Server, was die Bewertung von Auftragsverarbeitungsverträgen erheblich vereinfacht. Sobald stattdessen eine Cloud-API wie OpenAI, Claude oder Gemini eingebunden wird, gelten für diesen Teil der Verarbeitung wieder die üblichen Anforderungen an Drittland-Übermittlungen und Auftragsverarbeitung, unabhängig davon, dass Dify selbst auf einem eigenen Server läuft. Der Serverstandort von Dify allein macht eine Anwendung also noch nicht automatisch DSGVO-konform, wenn im Hintergrund weiterhin Daten an einen US-Anbieter fließen.

Häufig gestellte Fragen

Brauche ich eine GPU, um Dify selbst zu hosten?
Nein. Dify selbst führt keine Modell-Inferenz aus, sondern orchestriert nur die Anfragen an externe Modell-Anbieter. Eine GPU wird höchstens gebraucht, wenn zusätzlich ein lokales Modell über Ollama auf demselben Server betrieben wird.

Kann ich Dify ohne eigene Domain betreiben?
Technisch ja, über die IP-Adresse des Servers. Für ein gültiges TLS-Zertifikat über Let's Encrypt wird jedoch eine Domain benötigt, weshalb ein produktiver Betrieb ohne Domain nicht empfehlenswert ist.

Wie viele Nutzer verkraftet eine einzelne Dify-Installation?
Das hängt stark von der Server-Größe und der Nutzung ab. Ein VPS mit 4 vCPUs und 8 GB RAM verkraftet in der Praxis mehrere gleichzeitige Chat-Sitzungen kleinerer Teams. Für größere Organisationen mit hunderten aktiven Nutzern empfiehlt sich stattdessen eine horizontale Skalierung der API- und Worker-Container.

Unterstützt Dify auch DeepSeek und Gemini als Modell-Anbieter?
Ja, beide sind laut offizieller Dokumentation als eigenständige Modell-Anbieter gelistet und lassen sich über die Einstellungen mit einem API-Schlüssel verbinden.

Was ist der Unterschied zwischen der Community-Edition und Dify Cloud?
Die Community-Edition ist der Open-Source-Code, den diese Anleitung selbst hostet, ohne die Nachrichten- oder Nutzer-Limits der kostenpflichtigen Cloud-Pläne. Dify Cloud übernimmt dafür Betrieb, Skalierung und Wartung gegen eine monatliche Gebühr.

Wie oft sollte ich meine Dify-Installation aktualisieren?
Angesichts der dokumentierten Sicherheitslücken der Vergangenheit empfiehlt sich ein Update-Rhythmus von maximal vier bis sechs Wochen, sicherheitsrelevante Patches sollten möglichst zeitnah eingespielt werden.

Kann ich mehrere Chatbots oder Workflows in einer Installation betreiben?
Ja, im Studio-Bereich lassen sich beliebig viele Anwendungen anlegen, jede mit eigener Wissensbasis, eigenem Modell und eigenem API-Schlüssel, innerhalb der Grenzen des verfügbaren Server-Speichers.

Ist eine selbst gehostete Dify-Instanz automatisch DSGVO-konform?
Nein. Das Self-Hosting vereinfacht die Kontrolle über den Serverstandort und Auftragsverarbeitungsverträge, ersetzt aber keine eigene Prüfung von Zugriffsrechten, Aufbewahrungsfristen und Dokumentation, wie sie bei jeder Verarbeitung personenbezogener Daten nötig ist.

Was passiert, wenn der Server während einer laufenden Konversation neu startet?
Da Chatverläufe und Sitzungsdaten in der PostgreSQL-Datenbank gespeichert werden und nicht nur im Arbeitsspeicher der Container liegen, bleibt eine Konversation nach einem Neustart erhalten. Nutzer müssen die Seite lediglich neu laden, sobald alle Container wieder im Status Up stehen.