Dify auf dem eigenen VPS — kompletter Setup-Guide

Warum Dify selbst hosten?

Dify ist eine Open-Source-Plattform für LLM-Anwendungen — RAG-Pipelines, Chatbots, Multi-Agent-Workflows, API-Deployment. Über 140.000 GitHub-Stars. Die Cloud-Version auf dify.ai ist schnell eingerichtet, aber du zahlst pro Token zusätzlich zu deinen LLM-API-Kosten, und deine Knowledge Base liegt auf Servern Dritter.

Selbst hosten bedeutet: keine Platform-Gebühren, keine Token-Limits außer denen deines LLM-Providers, alle Daten auf deinem Server. Ich betreibe Dify seit über einem Jahr auf einem eigenen VPS — dieser Guide ist die Zusammenfassung dessen, was tatsächlich funktioniert und wo es bricht.

Was du am Ende hast

• Eine Dify-Instanz unter eigener Domain mit HTTPS
• Postgres + Redis + Weaviate im Docker-Compose-Stack
• Modell-Anbindung an OpenAI, Anthropic, Ollama — parallel möglich
• RAG-Pipeline mit eigener Knowledge Base
• API-Endpunkte für externe Automation (n8n, eigene Skripte)

Voraussetzungen

Hardware

Unter 2 GB RAM wird PostgreSQL von Dify kontinuierlich in den Swap drängen — Docker-Container sterben dann an OOM-Kills. Ich habe das ausprobiert: auf einem 1-GB-VPS läuft Dify etwa 10 Minuten, dann stirbt der worker-Container. stabilize lässt es sich erst ab 4 GB.

Software

# Docker + Compose-Plugin prüfen
docker --version         # >= 24.0
docker compose version   # v2.x

# git
git --version            # >= 2.34

# Ports müssen frei sein: 80, 443, 5001 (Web), 3000 (API)
ss -tlnp | grep -E ':(80|443|5001|3000)\b'

Wenn Port 80 oder 443 bereits von einem anderen Webserver belegt sind — etwa ein Blog oder eine Landingpage — brauchst du einen Reverse Proxy davor. Dazu unten mehr.

Domain und DNS

Mindestens eine Domain mit A-Record auf die VPS-IP. Für HTTPS brauchst du einen Domainnamen — eine nackte IP bringt Let's Encrypt nicht zum Laufen.

Installation — Schritt für Schritt

Schritt 1: Repo klonen

cd /opt
git clone https://github.com/langgenius/dify.git
cd dify

Schritt 2: Environment-Datei erstellen

cp docker/.env.example docker/.env

Diese Kopie ist der wichtigste Schritt — ohne eigene .env startet Dify mit Default-Werten, die in Produktion nicht tragbar sind.

Schritt 3: Secrets generieren

# Secret Keys austauschen — niemals die Defaults in Produktion lassen
SECRET_KEY_BASE=$(openssl rand -base64 42)
echo "SECRET_KEY_BASE=$SECRET_KEY_BASE" >> docker/.env

# MongoDB / Redis Passwörter ändern
sed -i 's/CONSOLE_API_KEY=.*/CONSOLE_API_KEY='"$(openssl rand -hex 24)"'/' docker/.env

Schritt 4: Ports anpassen (falls belegt)

# In docker/.env:
EXPOSE_PORT=5002        # wenn 5001 belegt ist
EXPOSE_API_PORT=3002

Schritt 5: Starten

cd docker
docker compose up -d

Erster Start zieht Images (~2 GB Download) und braucht 3–5 Minuten. Status prüfen:

docker compose ps
# Alle Services sollten "running" oder "healthy" zeigen

Schritt 6: Firewall

ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Die Ports 5001 und 3000 nicht öffnen — die sollen nur intern erreichbar sein. Zugriff von außen ausschließlich über Reverse Proxy mit HTTPS.

Schritt 7: Reverse Proxy mit Caddy

# /etc/caddy/Caddyfile
dify.deine-domain.de {
    reverse_proxy localhost:5002
    encode gzip
    header {
        X-Content-Type-Options nosniff
        X-Frame-Options DENY
        Referrer-Policy strict-origin-when-cross-origin
    }
}

systemctl reload caddy

Caddy zieht automatisch Let's Encrypt-Zertifikate. Bei Nginx analog mit certbot --nginx.

Schritt 8: Erstes Setup

Browser auf https://dify.deine-domain.de — Dify zeigt den Init-Dialog für den Admin-Account. E-Mail und Passwort setzen, Instanz konfigurieren. Keine Default-Passwörter verwenden.

Typische Fehler und wie man sie findet

Fehler 1: Worker stirbt an OOM-Kill

Symptom: docker compose logs worker zeigt Killed oder OOM.

Ursache: VPS hat unter 4 GB RAM, Postgres + Redis + Worker konkurrieren.

# In docker/.env:
WORKER_MAX_CONCURRENCY=2   # Default ist höher

docker compose up -d --force-recreate worker

Ab 4 GB RAM tritt das Problem nicht mehr auf. Unter 2 GB ist Dify nicht stabil betreibbar — egal welche Konfiguration.

Fehler 2: LLM-API-Key funktioniert nicht — "Invalid Token"

Symptom: Beim Chatten erscheint 401 Unauthorized oder Invalid token.

Ursache: Häufigster Fehler sind Leerzeichen am Anfang oder Ende des Keys beim Copy-Paste. Bei Anthropic: die Organization-ID muss gesetzt sein, wenn du mehrere Orgs hast.

Fix: Key in den Provider-Einstellungen neu eintragen — ohne Whitespace. Für OpenAI: sk-proj-*-Keys funktionieren, Organization-ID nicht vergessen.

Fehler 3: RAG-Dokumente bleiben "Processing"

Symptom: Hochgeladenes PDF ist ewig im Status Queued oder Processing.

Ursache: Embedding-Modell nicht korrekt konfiguriert, oder Rate-Limit beim Embedding-Provider erreicht. Dify bricht nach 3 Fehlversuchen ab — nicht unendlich oft.

# In docker/.env:
TEXT_EMBEDDING_MODEL=text-embedding-3-small

# Worker-Container neu starten:
docker compose restart worker

Dokument danach neu hochladen, nicht nur restarten — der Job-Status wird nicht automatisch zurückgesetzt.

Fehler 4: Let's Encrypt-Zertifikat schlägt fehl

Symptom: Caddy oder Nginx hat HTTPS nicht hinbekommen, Browser warnt.

Ursache: HTTP-01-Challenge verlangt Port 80 erreichbar. Ein anderer Webserver blockiert den Challenge-Response.

ss -tlnp | grep :80
# Wenn Nginx läuft: stoppen, Caddy die Ports überlassen
systemctl stop nginx
systemctl disable nginx
systemctl restart caddy

Alternative: DNS-01-Challenge mit Cloudflare-Plugin — dann braucht es Port 80 nicht.

Fehler 5: 502 nach Update

Symptom: Nach git pull && docker compose up -d geht nichts mehr.

Ursache: Postgres-Migration nicht gelaufen oder inkompatibles Image-Tag.

cd /opt/dify
git pull origin main
cd docker
docker compose pull
docker compose down
docker compose up -d
docker compose exec api flask db upgrade

Fehler 6: Logs laufen voll, Disk wird knapp

Symptom: Docker-Storage explodiert mit Logs. Disk-Usage steigt monoton.

# /etc/docker/daemon.json anlegen:
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

systemctl restart docker

Danach ist jedes Log-File auf 30 MB gedeckelt. Das hat mir einmal 8 GB Disk zurückgeholt.

Fehler 7: RAG-Queries werden langsam ab 50.000 Vektoren

Symptom: RAG-Queries dauern über 10 Sekunden, API-Responses zeitarkann aus.

Ursache: Default-Vector-Store ist Weaviate im selben Docker-Compose-Stack. Ab ~50.000 Vektoren wird die Performance ohne Index-Tuning schlecht.

Fix: docker-compose.override.yml für Weaviate anlegen, QUERY_DEFAULTS_LIMIT und Index-Parameter anpassen. Ab 100.000 Vektoren Wechsel auf Qdrant oder pgvector erwägen.

Kosten

Die Frage ist nicht nur "was kostet der VPS" sondern "was kostet der gesamte Stack im Betrieb". Hier meine tatsächlichen monatlichen Kosten:

Der variable Posten ist die LLM-API. Mit Ollama und einem lokalen 7B-Modell ist der API-Kostenposten null — du zahlst nur den Strom bzw. den VPS. Mit OpenAI gpt-4o kommen schnell 20–50 € pro Monat für eine knowledge-Base-aktive Instanz dazu, je nach Query-Volumen.

Ollama als Model-Provider (keine API-Kosten)

Wenn du nicht pro Token an OpenAI zahlen willst, kannst du Ollama als Provider einbinden. Voraussetzung: eine Maschine mit genug CPU oder GPU für das Modell. Der Dify-VPS selbst hat für lokale 7B-Modelle nicht genug Power — ich betreibe Ollama auf einem separaten Server.

In Dify unter Settings → Model Provider → Ollama die URL des Ollama-Servers eintragen (z. B. http://server-ip:11434), Modellname angeben, API-Key-Feld leer lassen. Firewall auf dem Ollama-Server:

ufw allow from dify-vps-ip to any port 11434

So habe ich Qwen2.5-7B für RAG und Mistral-7B für Chat laufen — ohne Token-Kosten. Performance: über 20 Tokens/s auf einer RTX 3090, etwa 3 Tokens/s CPU-only. Für RAG-Fragen reicht ein 3B-Modell und läuft auch auf CPU tolerierbar.

Fazit

Dify auf dem eigenen VPS ist kein 25-Minuten-Projekt wie die offizielle Quickstart-Doku weismacht. Die eigentliche Installation dauert 20 Minuten — die ersten drei Monate danach verbringst du mit OOM-Kills, API-Rate-Limits, Embedding-Problemen und Reverse-Proxy-Fehlern. Das ist die Realität von Self-Hosted-AI.

Aber danach hast du eine KI-Workflow-Plattform, die keine Cloud-Gebühren kostet, keine Token-Limits pro Monat hat, und alle Daten auf deinem Server bleiben. Für Agenten-Systeme und RAG-Anwendungen in echtem Produktivbetrieb ist Dify mein primäres Werkzeug — und dieser Stack läuft seit über einem Jahr stabil.

Wer nur schnell einen Chatbot bauen will, ist mit der Cloud-Version von dify.ai schneller dran. Wer aber Kontrolle will — über Daten, über Kosten, über Modellwahl — kommt am Self-Hosting nicht vorbei.

Ein Wort zu den versteckten Kosten: Selbst-Hosting bedeutet, du bist auch für Backups, Updates und Security-Patches verantwortlich. Ein pg_dump-Cron alle 24 Stunden und ein Healthcheck-Skript, das den Stack alle 5 Minuten prüft und bei Timeout neu startet, gehören zum Minimum. Ohne das merkst du erst, dass etwas kaputt ist, wenn User sich melden. Bei Cloud-Hosting ist das alles inklusive — bei Self-Hosting bist du selbst in der Pflicht.

Die Lernkurve ist real. Aber nach den ersten drei Monaten, wenn der Stack stabil läuft und du das Fehler-Repertoire kennst, ist der Wartungsaufwand minimal: ein docker compose pull && docker compose up -d pro Monat, ein Backup-Cron im Hintergrund, gelegentlich ein Blick auf die Disk-Auslastung. Der Anfangsaufwand zahlt sich durch dauerhafte Cloud-Unabhängigkeit zurück.