Mit Dify baust Du auf Deinem eigenen Server eine komplette Plattform für KI-Apps und Agenten auf, ohne jede Funktion selbst zu programmieren. Dify (Projekt langgenius/dify) ist eine quelloffene LLMOps-Plattform: Du erstellst darin Chatbots, autonome Agenten, visuelle Workflows (Chatflows) und RAG-Wissensdatenbanken, bindest beliebige Modell-Provider wie OpenAI, Anthropic oder lokales Ollama ein und veröffentlichst die fertige App als Web-Oberfläche oder API. Für wen lohnt sich das? Für Mittelstands-IT und Admins, die KI-Anwendungen datenschutzkonform im eigenen Netz betreiben wollen, und für ambitionierte Heimserver-Nutzer. Anders als ein generischer Automatisierungs-Baukasten oder eine simple Dokumenten-Chat-App ist Dify auf den kompletten Lebenszyklus von LLM-Anwendungen ausgelegt: Entwickeln, Testen, Veröffentlichen, Überwachen.

Diese Anleitung zeigt Dir den offiziellen Weg per Docker Compose auf einem Linux-Server (Debian 12 oder Ubuntu 24.04): Repository klonen, .env anlegen, Stack starten, Admin-Konto einrichten, Modell-Provider verbinden und die erste App bauen. Dazu kommen Reverse-Proxy, Update-Workflow und Backup.

Kurzfassung: Dify wird mit drei Befehlen installiert. Repository klonen, ins Verzeichnis dify/docker wechseln, .env aus der Vorlage kopieren und den Stack starten:

git clone --branch 1.14.2 https://github.com/langgenius/dify.git
cd dify/docker && cp .env.example .env
docker compose up -d

Danach rufst Du http://DEIN-SERVER/install im Browser auf, legst das Admin-Konto an und trägst unter Settings → Model Provider Deinen API-Key ein. Fertig ist die KI-App-Plattform.

Voraussetzungen

Dify selbst orchestriert nur die Dienste und braucht keine GPU. Rechenleistung für die Modelle kommt entweder von externen Anbietern (OpenAI, Anthropic) oder von einer separaten Serving-Engine wie Ollama. Plane den Server trotzdem nicht zu knapp, der Stack startet rund neun Container gleichzeitig.

Komponente	Minimum / Empfehlung
CPU	mind. 2 Kerne (4+ empfohlen)
RAM	mind. 4 GiB (8 GiB empfohlen)
Betriebssystem	Debian 12 oder Ubuntu 24.04 (Linux-Server)
Docker Engine	19.03 oder neuer
Docker Compose	2.24.0 oder neuer
Speicherplatz	ab ca. 20 GB frei (Images, Volumes, Wissensbasis)
GPU	für Dify nicht nötig; nur für lokales LLM-Serving sinnvoll

Prüfe vor dem Start, ob Docker und Compose passen. Eine zu alte Compose-Version (unter 2.24.0) lässt den Start fehlschlagen:

docker --version
docker compose version

Wenn auf dem Server bereits ein Webserver oder Reverse-Proxy auf Port 80/443 läuft, merke Dir das für Schritt 3, dort stellst Du den Host-Port um. Eine Domain ist optional, für den produktiven Betrieb mit HTTPS aber dringend zu empfehlen.

GPU-Betrieb: CPU vs. nvidia-container-toolkit

Dify rechnet die Modelle nicht selbst. Wenn Du Modelle lokal betreiben willst (etwa Ollama oder LocalAI), läuft das auf CPU oder GPU. Für GPU-Beschleunigung installierst Du auf dem Host das nvidia-container-toolkit und gibst der Serving-Engine das GPU-Device frei. Dify selbst wird dann nur über eine Base-URL angebunden, mehr dazu in Schritt 6. Ohne GPU funktioniert alles ebenfalls, nur langsamer bei lokalen Modellen. Cloud-Provider (OpenAI/Anthropic) brauchen ohnehin keine lokale GPU.

Schritt 1: Repository klonen und Verzeichnis vorbereiten

Melde Dich per SSH am Server an und klone das offizielle Dify-Repository. Wir verwenden den festen Release-Tag 1.14.2 (Stand dieser Anleitung, veröffentlicht am 19.05.2026), damit Du eine reproduzierbare Version bekommst:

git clone --branch 1.14.2 https://github.com/langgenius/dify.git
cd dify/docker

Alle für den Betrieb relevanten Dateien liegen im Unterverzeichnis docker: die docker-compose.yaml, die Vorlage .env.example und (nach dem ersten Start) das Verzeichnis volumes für die Persistenz. Wenn Du immer die neueste stabile Version willst, kannst Du den Tag auch automatisch ermitteln:

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

Schritt 2: .env aus der Vorlage anlegen und absichern

Dify steuert sämtliche Einstellungen über eine .env-Datei. Kopiere die mitgelieferte Vorlage:

cp .env.example .env

Öffne anschließend die .env und passe die wichtigsten Werte an. Die Standard-Passwörter difyai123456 für Datenbank und Redis musst Du vor produktivem Einsatz unbedingt ändern. Setze außerdem einen eigenen SECRET_KEY (bei leerem Wert wird zwar ein persistenter Schlüssel erzeugt, für Produktion ist ein expliziter Wert aber sauberer):

# --- Sicherheit (anpassen!) ---
SECRET_KEY=DEIN-LANGER-ZUFALLSSTRING
INIT_PASSWORD=

# --- Datenbank (PostgreSQL) ---
DB_USERNAME=postgres
DB_PASSWORD=DEIN-DB-PASSWORT
DB_DATABASE=dify

# --- Redis ---
REDIS_PASSWORD=DEIN-REDIS-PASSWORT

# --- Vektor-Datenbank ---
VECTOR_STORE=weaviate

# --- DB-Migrationen automatisch ausfuehren ---
MIGRATION_ENABLED=true

# --- Ports (Host) ---
EXPOSE_NGINX_PORT=80
EXPOSE_NGINX_SSL_PORT=443

Einen sicheren SECRET_KEY erzeugst Du schnell auf der Kommandozeile:

openssl rand -base64 42

Wichtig für den produktiven Betrieb hinter Domain/Reverse-Proxy: Trage zusätzlich die öffentlichen URLs ein, sonst brechen Links, API-Endpunkte und veröffentlichte Apps:

CONSOLE_API_URL=https://DEINE-DOMAIN.de
CONSOLE_WEB_URL=https://DEINE-DOMAIN.de
SERVICE_API_URL=https://DEINE-DOMAIN.de
APP_API_URL=https://DEINE-DOMAIN.de
APP_WEB_URL=https://DEINE-DOMAIN.de

Schritt 3: compose.yaml verstehen und Ports anpassen

Die mitgelieferte docker-compose.yaml ist umfangreich (sie referenziert viele Variablen aus der .env). Du musst sie nicht von Hand schreiben, sie ist Teil des Repositorys. Damit Du den Aufbau verstehst und einen reproduzierbaren, schlankeren Stack im Blick hast, hier eine vollständige, lauffähige Beispiel-compose.yaml mit den Kerndiensten und festen image-Tags. Sie zeigt das Prinzip: Kerncontainer (api, worker, web, plugin_daemon) plus Abhängigkeiten (PostgreSQL, Redis, Weaviate, Sandbox, ssrf_proxy, nginx):

x-shared-env: &shared-api-worker-env
  SECRET_KEY: ${SECRET_KEY:-}
  DB_USERNAME: ${DB_USERNAME:-postgres}
  DB_PASSWORD: ${DB_PASSWORD:-difyai123456}
  DB_HOST: db
  DB_PORT: 5432
  DB_DATABASE: ${DB_DATABASE:-dify}
  REDIS_HOST: redis
  REDIS_PORT: 6379
  REDIS_PASSWORD: ${REDIS_PASSWORD:-difyai123456}
  VECTOR_STORE: ${VECTOR_STORE:-weaviate}
  WEAVIATE_ENDPOINT: http://weaviate:8080
  MIGRATION_ENABLED: ${MIGRATION_ENABLED:-true}

services:
  # API-Backend
  api:
    image: langgenius/dify-api:1.14.2
    restart: always
    environment:
      <<: *shared-api-worker-env
      MODE: api
    depends_on:
      - db
      - redis
    volumes:
      - ./volumes/app/storage:/app/api/storage

  # Hintergrund-Worker (Celery)
  worker:
    image: langgenius/dify-api:1.14.2
    restart: always
    environment:
      <<: *shared-api-worker-env
      MODE: worker
    depends_on:
      - db
      - redis
    volumes:
      - ./volumes/app/storage:/app/api/storage

  # Geplante Aufgaben
  worker_beat:
    image: langgenius/dify-api:1.14.2
    restart: always
    environment:
      <<: *shared-api-worker-env
      MODE: beat
    depends_on:
      - db
      - redis

  # Web-Frontend
  web:
    image: langgenius/dify-web:1.14.2
    restart: always
    environment:
      CONSOLE_API_URL: ${CONSOLE_API_URL:-}
      APP_API_URL: ${APP_API_URL:-}

  # Plugin-Daemon (laedt Provider-Plugins aus dem Marketplace)
  plugin_daemon:
    image: langgenius/dify-plugin-daemon:1.14.2-local
    restart: always
    environment:
      <<: *shared-api-worker-env
    volumes:
      - ./volumes/plugin_daemon:/app/storage
    depends_on:
      - db
      - redis

  # PostgreSQL
  db:
    image: postgres:15-alpine
    restart: always
    environment:
      POSTGRES_USER: ${DB_USERNAME:-postgres}
      POSTGRES_PASSWORD: ${DB_PASSWORD:-difyai123456}
      POSTGRES_DB: ${DB_DATABASE:-dify}
    volumes:
      - ./volumes/db/data:/var/lib/postgresql/data

  # Redis
  redis:
    image: redis:6-alpine
    restart: always
    command: redis-server --requirepass ${REDIS_PASSWORD:-difyai123456}
    volumes:
      - ./volumes/redis/data:/data

  # Vektor-Datenbank (Standard)
  weaviate:
    image: semitechnologies/weaviate:1.19.0
    restart: always
    environment:
      PERSISTENCE_DATA_PATH: /var/lib/weaviate
      DEFAULT_VECTORIZER_MODULE: none
    volumes:
      - ./volumes/weaviate:/var/lib/weaviate

  # Code-Sandbox
  sandbox:
    image: langgenius/dify-sandbox:0.2.10
    restart: always
    environment:
      GIN_MODE: release

  # Schutz gegen SSRF
  ssrf_proxy:
    image: ubuntu/squid:latest
    restart: always

  # Reverse-Proxy / Einstiegspunkt
  nginx:
    image: nginx:latest
    restart: always
    depends_on:
      - api
      - web
    ports:
      - "${EXPOSE_NGINX_PORT:-80}:80"
      - "${EXPOSE_NGINX_SSL_PORT:-443}:443"

Diese Beispieldatei verdeutlicht die Struktur. Im Produktivbetrieb nutzt Du die offizielle docker-compose.yaml aus dem Repository, weil sie alle Feinheiten (Health-Checks, ssrf_proxy-Config, Netzwerke) korrekt mitbringt. Beachte den restart: always bei jedem Dienst und die Volumes unter ./volumes, dort liegt Deine gesamte Persistenz.

Port belegt? Läuft auf dem Host bereits ein Reverse-Proxy (Caddy, Traefik, nginx), setze in der .env einen freien Host-Port, etwa:

EXPOSE_NGINX_PORT=8080

Schritt 4: Stack starten und Status prüfen

Jetzt startest Du den kompletten Stack im Hintergrund. Beim ersten Start lädt Docker alle Images herunter, das kann je nach Verbindung einige Minuten dauern:

docker compose up -d

Prüfe danach, ob alle Dienste laufen. Du solltest rund neun Container im Zustand running bzw. healthy sehen (api, worker, worker_beat, web, plugin_daemon, db, redis, weaviate, nginx, ssrf_proxy, sandbox):

docker compose ps

Falls ein Dienst nicht startet, hilft ein Blick in die Logs. Gerade api und plugin_daemon sind aussagekräftig:

docker compose logs -f api plugin_daemon

Die Datenbank-Migrationen laufen dank MIGRATION_ENABLED=true automatisch beim Start des api-Containers, Du musst nichts manuell anstoßen.

Schritt 5: Web-UI öffnen und Admin-Konto anlegen

Dify bringt kein Standard-Login mit. Den Administrator-Account legst Du beim ersten Aufruf selbst an. Öffne im Browser die Installationsseite (ersetze DEIN-SERVER durch IP oder Domain):

http://DEIN-SERVER/install

Trage E-Mail, Benutzername und ein sicheres Passwort ein und schließe die Einrichtung ab. Danach landest Du auf der Login-Seite unter http://DEIN-SERVER und meldest Dich mit diesen Zugangsdaten an. Beim ersten Login siehst Du das leere Dashboard, von hier aus erstellst Du Apps und verwaltest die Wissensdatenbanken.

Schritt 6: Modell-Provider einbinden (OpenAI, Anthropic, Ollama)

Ohne Modell-Provider kann Dify keine Antworten erzeugen. Die Provider sind Plugins, die der plugin_daemon bei Bedarf aus dem Dify Marketplace lädt, dafür braucht der Server ausgehenden Internetzugang. Gehe im Dashboard auf Settings → Model Provider, wähle den gewünschten Anbieter und trage die Zugangsdaten ein.

Cloud-Provider: OpenAI und Anthropic

Bei OpenAI und Anthropic genügt der jeweilige API-Key. Optional kannst Du eine abweichende Base-URL oder einen Proxy hinterlegen. Nach dem Speichern stehen die Modelle (z. B. GPT- oder Claude-Modelle) sofort in jeder App zur Auswahl.

Lokales Modell: Ollama anbinden

Willst Du Modelle lokal betreiben, läuft das oft über Ollama. Wichtig: In einem Container zeigt localhost auf den Container selbst, nicht auf den Host. Verwende deshalb die spezielle Adresse host.docker.internal. Trage unter Ollama als Base-URL ein:

http://host.docker.internal:11434

Unter Linux ist host.docker.internal nicht automatisch verfügbar. Ergänze in der compose-Datei beim betreffenden Dienst einen extra_hosts-Eintrag:

    extra_hosts:
      - "host.docker.internal:host-gateway"

Für GPU-beschleunigtes Serving installierst Du Ollama (oder LocalAI) separat mit nvidia-container-toolkit und gibst der Engine das GPU-Device. Dify bleibt davon unberührt und spricht die Engine nur über die Base-URL an.

Schritt 7: Erste App und RAG-Wissensdatenbank bauen

Jetzt kommt der eigentliche Mehrwert von Dify. Im Dashboard erstellst Du über Create App eine neue Anwendung. Du hast mehrere App-Typen zur Auswahl:

Chatbot — klassischer Dialog-Assistent mit Systemprompt.
Agent — nutzt Tools/Funktionen, um Aufgaben mehrstufig zu lösen.
Workflow — visuell verkettete Schritte für reproduzierbare Abläufe.
Chatflow — Kombination aus Dialog und Workflow-Logik.

Für eine Wissensdatenbank (RAG) gehst Du auf Knowledge, legst eine neue Wissensbasis an und lädst Dokumente hoch (PDF, Text, Markdown). Dify zerlegt die Dokumente, erzeugt Embeddings und speichert sie in der Vektor-Datenbank Weaviate. In Deiner Chatbot- oder Chatflow-App verknüpfst Du diese Wissensbasis als Kontext, sodass die KI auf Basis Deiner eigenen Dokumente antwortet.

Hinweis zur Vektor-DB: Lege VECTOR_STORE vor dem ersten Aufbau der Wissensbasis fest (Standard: weaviate, alternativ z. B. qdrant, milvus oder pgvector). Ein nachträglicher Wechsel erfordert eine vollständige Re-Indexierung aller Dokumente.

App veröffentlichen: Web und API

Ist die App fertig, klickst Du auf Publish. Dify stellt Dir zwei Wege bereit: eine fertige Web-Oberfläche, die Du teilen oder einbetten kannst, und eine REST-API mit eigenem API-Key, über die Du die App in Deine Software integrierst. Damit Links und API-Endpunkte stimmen, müssen die in Schritt 2 gesetzten URL-Variablen korrekt auf Deine Domain zeigen.

Schritt 8: Reverse-Proxy und HTTPS

Für den produktiven Betrieb solltest Du Dify hinter einem Reverse-Proxy mit gültigem TLS-Zertifikat betreiben. Du hast zwei Varianten: Entweder Du nutzt die im Stack enthaltene nginx-Konfiguration mit den SSL-Variablen aus der .env, oder Du setzt einen eigenen Reverse-Proxy (z. B. nginx oder Caddy) auf dem Host davor und leitest auf den intern gemappten Dify-Port um.

Beispiel für einen vorgelagerten nginx, der auf einen umgestellten Host-Port (8080) weiterleitet:

server {
    listen 443 ssl;
    server_name DEINE-DOMAIN.de;

    ssl_certificate     /etc/letsencrypt/live/DEINE-DOMAIN.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/DEINE-DOMAIN.de/privkey.pem;

    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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;
    }
}

Vergiss in diesem Fall nicht, in der .env die CONSOLE_*_URL, SERVICE_API_URL und APP_*_URL auf https://DEINE-DOMAIN.de zu setzen und den Stack neu zu starten. Das große client_max_body_size ist wichtig, damit Du große Dokumente in die Wissensbasis hochladen kannst.

Schritt 9: Update und Backup

Updates laufen über das übliche Compose-Muster: Repository aktualisieren, neue Images ziehen, Stack neu starten. Führe die Befehle im Verzeichnis dify/docker aus:

cd dify
git fetch --tags
git checkout 1.14.2        # oder neueren Tag
cd docker
docker compose down
docker compose pull        # neue Images ziehen
docker compose up -d       # neu starten, DB-Migration laeuft automatisch

Gleiche nach jedem Update Deine .env mit der aktuellen .env.example ab, neue Releases bringen oft zusätzliche Variablen mit. Die Datenbank-Migration läuft dank MIGRATION_ENABLED=true beim Start automatisch.

Für ein konsistentes Backup stoppst Du den Stack kurz und sicherst das gesamte volumes-Verzeichnis samt .env:

cd dify/docker
docker compose down
tar czf dify-backup-$(date +%F).tar.gz volumes/ .env
docker compose up -d

Im volumes-Verzeichnis liegen die wirklich wichtigen Daten: db (PostgreSQL mit Apps und Konfiguration), app/storage (Datei-Uploads der Wissensbasis), weaviate (Vektor-Index) und plugin_daemon (installierte Provider-Plugins). Bewahre die Backups außerhalb des Servers auf.

Troubleshooting

Ollama/LocalAI meldet „Connection refused“: In Docker zeigt localhost auf den Container, nicht auf den Host. Nutze http://host.docker.internal:11434. Unter Linux funktioniert das nur mit extra_hosts: ["host.docker.internal:host-gateway"] in der compose-Datei.

Veröffentlichte Apps oder Links sind kaputt: Wahrscheinlich sind die öffentlichen URLs nicht gesetzt. Trage CONSOLE_API_URL, CONSOLE_WEB_URL, SERVICE_API_URL, APP_API_URL und APP_WEB_URL in der .env auf Deine echte Domain ein und starte mit docker compose up -d neu.

Start schlägt fehl: Prüfe die Docker-Compose-Version mit docker compose version. Unter 2.24.0 kann der Start scheitern, aktualisiere das Compose-Plugin.

Port 80/443 bereits belegt: Setze EXPOSE_NGINX_PORT in der .env auf einen freien Port (z. B. 8080) und leite per Reverse-Proxy dorthin um, statt einen Port-Konflikt zu riskieren.

Modell-Provider lässt sich nicht laden: Der plugin_daemon bezieht Provider-Plugins aus dem Marketplace und braucht ausgehenden Internetzugang. In abgeschotteten (air-gapped) Umgebungen musst Du die Plugins manuell offline bereitstellen. Logs prüfen mit docker compose logs -f plugin_daemon.

Häufige Fragen

Braucht Dify zwingend eine GPU?

Nein. Dify orchestriert nur die Dienste und kommt mit 2 CPU-Kernen und 4 GiB RAM aus. Eine GPU ist nur dann sinnvoll, wenn Du Modelle lokal über Ollama oder LocalAI betreibst. Cloud-Modelle von OpenAI oder Anthropic rechnen ohnehin extern.

Wie unterscheidet sich Dify von n8n oder AnythingLLM?

Dify ist eine spezialisierte LLMOps-Plattform für den gesamten Lebenszyklus von KI-Apps (Entwickeln, Testen, Veröffentlichen, Überwachen). n8n ist ein generischer Automatisierungs-Baukasten für beliebige Systeme, während AnythingLLM auf einfache RAG-Chats mit Dokumenten fokussiert ist. Für komplexe Agenten und Workflows mit Modell-Verwaltung ist Dify die passendere Wahl.

Wo speichert Dify meine Daten?

Alle persistenten Daten liegen im Verzeichnis dify/docker/volumes: die PostgreSQL-Datenbank, die Datei-Uploads der Wissensbasis, der Weaviate-Vektorindex und die Plugin-Daten. Sicherst Du dieses Verzeichnis plus die .env, hast Du ein vollständiges Backup.

Welche Vektor-Datenbank soll ich nehmen?

Für den Einstieg ist der Standard weaviate bestens geeignet. Alternativ unterstützt Dify unter anderem qdrant, milvus und pgvector. Lege die Wahl über VECTOR_STORE fest, bevor Du die erste Wissensbasis aufbaust, ein späterer Wechsel erfordert eine Re-Indexierung.

Kann ich mehrere Modell-Provider gleichzeitig nutzen?

Ja. Du kannst beliebig viele Provider unter Settings → Model Provider hinterlegen, etwa OpenAI für Chat, Anthropic für lange Kontexte und Ollama für lokale Embeddings. In jeder App wählst Du dann gezielt das passende Modell.

Wie aktualisiere ich Dify gefahrlos?

Mache vorher ein Backup des volumes-Verzeichnisses, checke den gewünschten Release-Tag aus, ziehe die neuen Images mit docker compose pull und starte mit docker compose up -d neu. Die DB-Migration läuft automatisch. Gleiche danach die .env mit der neuen .env.example ab.

Fazit

Mit Docker Compose hast Du Dify in wenigen Minuten als vollwertige KI-App-Plattform auf dem eigenen Server. Repository klonen, .env absichern, docker compose up -d und das Admin-Konto unter /install anlegen, mehr braucht es für den Start nicht. Wer produktiv geht, ändert die Standard-Passwörter, setzt einen eigenen SECRET_KEY, trägt die öffentlichen URLs ein und stellt einen Reverse-Proxy mit HTTPS davor. Danach baust Du Chatbots, Agenten, Workflows und RAG-Wissensdatenbanken mit eigenen Dokumenten und veröffentlichst sie als Web-App oder API. Updates und Backups folgen dem vertrauten Compose-Muster. So behältst Du Deine KI-Anwendungen und Daten komplett unter eigener Kontrolle.

Weiterführende Anleitungen und Quellen

Wenn Du tiefer in das Thema einsteigen willst, helfen Dir diese Anleitungen aus unserem Wissensbereich weiter:

Docker Compose Grundlagen: Multi-Container-Stacks sauber betreiben — das Fundament für jeden Self-Hosting-Stack wie Dify.
AnythingLLM mit Docker: mit eigenen Dokumenten chatten (RAG) — die schlankere Alternative für reine Dokumenten-Chats.
ComfyUI mit Docker: KI-Bildgenerierung mit Stable Diffusion — passend, wenn Du GPU-Serving auf dem Host einrichten willst.
Weitere Anleitungen aus der Kategorie Künstliche Intelligenz

Offizielle Quellen: