Dify vereint Prompt-Orchestrierung, Wissensdatenbank, Workflows und Agenten in einer visuellen Oberfläche. Die Plattform produziert keine eigenen Modelle; die Fähigkeiten kommen von den angebundenen Anbietern. Teams in China betreiben Dify häufig selbst und binden über eine OpenAI-kompatible Schnittstelle ein einheitliches API-Gateway an, sodass Keys, Modelle und Verbrauch zentral verwaltet werden.

Dieser Artikel folgt dem Ablauf: bereitstellen, Anbieter hinzufügen, Parameter eintragen, minimalen Workflow bauen, im Team nutzen und absichern. Oberflächen, Plugins und Variablennamen richten sich nach der aktuellen Dokumentation; Modellumfang und Preise entnehmen Sie den Modellpreisen, Preise können sich ändern.

Hinweis: Dify ist eine Marke der jeweiligen Rechteinhaber. Dieser Artikel beschreibt ausschließlich die technische Anbindung; es besteht keine Zugehörigkeit zu den genannten Anbietern.

1. Cloud oder Selbstbetrieb

Dify bietet einen Cloud-Dienst und eine selbst betreibbare Community Edition. Cloud spart Betriebsaufwand und eignet sich für schnelle Tests; beim Selbstbetrieb bleiben die Daten auf dem eigenen Server, was für Teams mit Anforderungen an Netzwerk, Daten und Rechte sinnvoll ist.

  • Nur zum Ausprobieren: Cloud ist schneller, Datenstandort und Netzwerkerreichbarkeit sollten aber vorher geklärt sein.
  • Interne Modelle oder eigene Plugins: Selbstbetrieb ist flexibler, dafür liegen Updates, Backups und HTTPS bei Ihnen.
  • Dauerhafte Teamnutzung: Mitgliederrechte, Key-Verwaltung und Budget müssen in beiden Fällen geplant werden.

2. Deployment mit Docker Compose

Für die Community Edition empfiehlt sich Docker Compose. Die aktuelle Dokumentation nennt mindestens 2 CPU-Kerne und 4 GiB Arbeitsspeicher; unter macOS sollten der Docker-Desktop-VM mindestens 8 GiB zugewiesen werden. Unter Linux werden Docker ab 19.03 und Compose ab 2.24 vorausgesetzt.

  1. Das Repository im aktuellen Release-Tag klonen; benötigt werden git, curl und jq.
  2. In das Verzeichnis dify/docker wechseln und .env.example nach .env kopieren.
  3. Mit docker compose up -d die Dienste starten.
  4. Mit docker compose ps den Status prüfen und warten, bis alle Dienste bereit sind.
  5. http://serveradresse/install öffnen, einen Administrator anlegen und sich anschließend über die Basisadresse anmelden.
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
docker compose up -d
docker compose ps

Standardmäßig ist die Instanz über Port 80 erreichbar, der Einstieg zur Initialisierung ist /install. Die Zahl der Container ändert sich mit der Version und sollte nicht aus älteren Anleitungen übernommen werden; ein init_permissions-Container mit Status Exited ist in der Regel eine einmalige Aufgabe und normal.

Die Konfiguration liegt in .env und überschreibt gleichnamige Variablen unter envs/. Nach Änderungen docker compose down und anschließend up -d ausführen. Vor einem Upgrade die Versionshinweise lesen, .env.example auf neue Variablen vergleichen und die alte Compose-Datei nicht unverändert weiterverwenden.

3. OpenAI-kompatiblen Modellanbieter hinzufügen

Nur Workspace-Owner und Administratoren verwalten Modellanbieter. Der Einstieg liegt meist unter Integrations oder in den Einstellungen unter Model Provider; zuerst das Plugin OpenAI-API-compatible installieren, dann über Setup die Zugangsdaten eintragen. Die Bezeichnungen ändern sich je nach Version; maßgeblich ist die aktuelle Dokumentation.

Typischer Ablauf:

  1. OpenAI-kompatibles Plugin installieren oder aktivieren.
  2. API-Key und eigene Base URL eintragen.
  3. Speichern und die Prüfung der Zugangsdaten abwarten.
  4. Modell hinzufügen und den Typ auswählen.
  5. Modellname, Kontextlänge und Fähigkeiten eintragen.
  6. Über den Testeinstieg oder eine minimale Anwendung verifizieren.
Feld Eingabe Häufiger Fehler
Base URL In der Regel bis /v1, etwa https://ai.zhongshangqihang.com/v1 Zusätzlich /chat/completions, Antwort 404
API Key Vollständig einfügen, kein manuelles Bearer Leerzeichen, Zeilenumbruch oder Anführungszeichen, Antwort 401
Modellname Identisch mit /v1/models oder den Modellpreisen Groß-/Kleinschreibung oder Datumssuffix falsch, model not found
Modelltyp LLM, Embedding, Rerank, Sprache usw. nach Zweck Falscher Typ, Modell erscheint nicht in der Anwendung
Kontextlänge Tatsächlich unterstützten Wert eintragen, Reserve lassen Theoretisches Maximum, lange Anfragen werden abgelehnt
Fähigkeiten Streaming, Funktionsaufruf, Vision nach tatsächlicher Unterstützung Agent-Tools schlagen fehl, Bild-Upload wird abgelehnt

Unter demselben Anbieter lassen sich mehrere Modelle einzeln konfigurieren. Namen sollten Zweck oder Version enthalten. Nach dem Einsatz eines Embedding-Modells in einer Wissensdatenbank ist die Dimension festgelegt; ein Modellwechsel erfordert meist einen Neuaufbau des Index.

4. Erst mit curl prüfen, dann in Dify testen

Wer direkt in Dify testet, kann bei einem Fehler kaum zwischen Gateway, Netzwerk und Feldeingabe unterscheiden. Prüfen Sie zuerst den Upstream per curl:

export ZSQH_API_KEY="sk-IhrSchluessel"

curl -sS "https://ai.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $ZSQH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"IhreModellID","messages":[{"role":"user","content":"Antworte nur mit OK"}]}' \
  -w "\nHTTP %{http_code}\n"

Eine Antwort mit choices zeigt, dass Key, Adresse und Modellname gültig sind. 401 deutet auf den Key, 404 auf den Pfad, model not found auf den Modellnamen. Die Base URL endet auf /v1 und enthält nicht den vollständigen Endpunktpfad; beim Key kein Bearer ergänzen, das übernimmt Dify.

Dify prüft die Zugangsdaten beim Speichern, aber eine bestandene Prüfung bedeutet nicht, dass jedes Modell nutzbar ist. Typ, Kontextlänge und Fähigkeiten müssen ebenfalls stimmen. Fehlt ein Testbutton, hilft eine einfachste Chat-Anwendung oder ein Aufruf der Anwendungs-API.

5. Einen minimalen Workflow bauen

Erst die kleinste Kette zum Laufen bringen, dann Nodes ergänzen. Beispiel Workflow:

  1. Im Studio einen Workflow oder Chatflow anlegen: für Dialoge Chatflow, für Stapelverarbeitung oder Automatisierung Workflow.
  2. Im Start-Node eine Eingabevariable definieren, etwa query.
  3. Einen LLM-Node hinzufügen, den angebundenen Anbieter und das Modell wählen und im Prompt die Variable des Start-Nodes referenzieren.
  4. Einen End-Node hinzufügen und die Ausgabe des LLM mit der Ausgabevariable verbinden.
  5. Einen Testlauf mit einer echten Frage starten und Eingaben, Ausgaben und Token-Verbrauch je Node prüfen.
  6. Nach erfolgreicher Prüfung veröffentlichen und über die eingebettete Seite oder die Anwendungs-API aufrufen.

Für Retrieval einen Knowledge-Retrieval-Node vor das LLM setzen und zuvor Embedding- und Rerank-Modell in den Workspace-Einstellungen konfigurieren. Für Verzweigungen einen Question-Classifier oder bedingten Zweig ergänzen. Der Agent-Node eignet sich für Tool-Aufrufe, benötigt aber ein Modell mit Funktionsaufruf; die Tool-Nutzung zuerst separat testen und erst dann in den Hauptablauf einbinden.

Jeder LLM- und Agent-Node kann ein eigenes Modell verwenden; Nodes ohne Auswahl nutzen das Standardmodell des Workspace. Kleine Modelle genügen für Klassifikation und Umschreibung, die finale Generierung übernimmt ein starkes Modell. Kritische Nodes sollten explizit gebunden werden, damit sich das Verhalten bei einem Wechsel des Standardmodells nicht verschiebt.

6. Teamnutzung: Mitglieder, Keys und Umgebungen

Workspace-Mitglieder sind üblicherweise Owner, Administrator, Editor und normales Mitglied; die Rechte richten sich nach Version und Tarif. Anbieter-Zugangsdaten gelten für den gesamten Workspace und sind keine persönliche Konfiguration; die Zahl der Administratoren sollte begrenzt bleiben.

  • Entwicklung und Produktion nutzen getrennte Anbieter-Zugangsdaten oder Keys, damit Limits und Widerruf sauber möglich sind.
  • Pro Anwendung einen eigenen API-Key erzeugen; der App-Key gilt nur für diese Anwendung, aber für alle deren Endnutzer.
  • Aufrufende Systeme unterscheiden Endnutzer über den Parameter user; den App-Key niemals in Frontend oder Client schreiben.
  • Die Service-API von Dify Cloud beginnt bei https://api.dify.ai/v1; beim Selbstbetrieb die eigene Domain plus /v1.
  • Der Request-Header lautet Authorization: Bearer <key>; Aufrufe nur im Backend.

Bei gemeinsamer Bearbeitung sollten Namensgebung, Variablen und Release-Prozess vorab vereinbart werden, sonst wird der Workflow schnell unwartbar. Für externe Anwendungen außerdem Versionierung und Rollback regeln und Prompts nicht direkt in der Produktionsanwendung ändern.

7. Checkliste für Sicherheit und Betrieb

  1. HTTPS aktivieren und Port 80 nicht direkt exponieren; der Reverse Proxy übernimmt Zertifikat und Zugriffskontrolle.
  2. /install nach der Initialisierung sperren, starke Passwörter verwenden und verfügbare Zwei-Faktor-Authentifizierung einschalten.
  3. Schlüssel nur in .env oder einem Secret-Manager ablegen, nie im Repository; bei Personalwechsel rotieren.
  4. In der Firewall nur notwendige Ports öffnen; Datenbank und Vektordatenbank nicht öffentlich exponieren.
  5. SSRF-Proxy und Netzwerkausgang des Selbstbetriebs nach aktueller Dokumentation konfigurieren und vor Netzänderungen die .env-Hinweise lesen.
  6. PostgreSQL, hochgeladene Dateien und .env regelmäßig sichern und Wiederherstellungen üben.
  7. Vor Upgrades sichern, Release-Tags festhalten und die Hinweise der jeweiligen Version befolgen.
  8. Im Gateway Budgets, Parallelität und Alarme setzen, damit Schleifenaufrufe das Kontingent nicht aufbrauchen.
  9. Code-Nodes nur mit selbst geprüftem Code betreiben; sie sind keine allgemeine Sicherheitsgrenze.

Sicherheit ist kein einmaliger Konfigurationsschritt, sondern ein Prozess, der bei Upgrades, Personalwechsel und Key-Rotation erneut geprüft werden muss.

8. Häufige Fehler auf einen Blick

  • 401 Unauthorized: Key falsch oder mit überflüssigen Zeichen; neu einfügen und prüfen, ob es der Key des richtigen Anbieters ist.
  • 404 oder model_not_found: Base-URL-Pfad falsch oder Modellname weicht ab; /v1 und Modellbezeichnung abgleichen.
  • Timeout: Dify erreicht den Upstream nicht oder dieser antwortet langsam; DNS, Firewall, Proxy und SSRF-Konfiguration prüfen.
  • Anbieter lässt sich nicht installieren: Plugin-Marktplatz nicht erreichbar oder Version inkompatibel; Netzwerk und aktuelle Dokumentation prüfen.
  • Modell in der Anwendung nicht auswählbar: Typ falsch oder Node nicht gebunden; Modellliste des Anbieters und Node-Konfiguration prüfen.
  • Fehler bei der Wissensdatenbank-Suche: Embedding-Dimension inkonsistent oder Index unvollständig; Modell wechseln oder Index neu aufbauen.

Häufige Fragen

Welche Mindestkonfiguration benötigt selbst betriebenes Dify?

Die aktuelle Dokumentation nennt 2 CPU-Kerne und 4 GiB Arbeitsspeicher, für die Docker-Desktop-VM unter macOS werden mindestens 8 GiB empfohlen. Parallelität und Größe der Wissensdatenbank kommen hinzu; in der Produktion sollten Reserven eingeplant werden.

Dify Cloud oder Selbstbetrieb – wie wählen?

Für schnelle Tests ohne Betriebsaufwand Cloud; wenn Daten auf dem eigenen Server bleiben sollen, interne Dienste oder eigene Plugins benötigt werden, Selbstbetrieb. Beide können OpenAI-kompatible Modelle anbinden; der Unterschied liegt bei Betriebsverantwortung und Netzwerkgrenzen.

Anbieter wurde hinzugefügt, das Modell ist aber nicht auswählbar?

Zuerst den Modelltyp prüfen, etwa ob ein Embedding- als LLM-Modell eingetragen wurde. Dann kontrollieren, ob das Modell unter diesem Anbieter angelegt und ob es in der Anwendung oder im Node gebunden ist. Manche Nodes akzeptieren nur Modelle mit bestimmten Fähigkeiten.

Muss jeder Node im Workflow ein eigenes Modell haben?

Ein eigenes Modell ist möglich, alternativ das Standardmodell des Workspace. Bei mehrstufigen Abläufen empfiehlt sich eine Aufteilung nach Aufgabe: kleine Modelle für Klassifikation und Extraktion, ein starkes Modell für die finale Generierung; kritische Nodes explizit binden.

Können alle im Team denselben API-Key verwenden?

Möglich, aber nicht empfehlenswert. Ein gemeinsamer Key erlaubt keine Zuordnung der Aufrufer, hat bei einem Leck eine große Wirkung und erschwert Limits. Besser Keys pro Anwendung oder Umgebung, Endnutzer über user unterscheiden und regelmäßig rotieren.

Nächste Schritte

Die Anbindung lässt sich in vier Schritte gliedern: Instanz starten, Upstream mit curl prüfen, Modellparameter nach tatsächlicher Unterstützung eintragen und die Node-Bindung mit einem minimalen Workflow verifizieren. Für einen einheitlichen OpenAI-kompatiblen Zugang und Verbrauchsverwaltung können Sie sich im ZSQH AI Gateway registrieren; Modelle und Abrechnung entnehmen Sie den Modellpreisen.

Weiterlesen: