Türkei (Türkisch)
Germany (German)
Worldwide (English)
CPU-Mindestbasis für die Dify-Docker-VM.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Self-hosted Dify besteht nicht nur aus Web/API; Worker, Datenbank, Redis, Sandbox und Storage arbeiten zusammen. „Container laufen“ reicht nicht als Production-Health-Nachweis.
Dify-Basis-RAM nicht als „Dify plus lokales Modell“ verstehen. Lokale Inference benötigt zusätzlich CPU/GPU-VRAM und System-RAM; Plattform und Inference getrennt dimensionieren.
Aktuelle Dify-Self-Host-Doku nennt mindestens 2 vCPU und 8 GiB RAM für die Docker-VM. Läuft Modell-Inference via Ollama/vLLM auf demselben Host, kommt diese Last hinzu.
Aktuelle Dify-Self-Host-Doku nennt mindestens 2 vCPU und 8 GiB RAM für die Docker-VM. Läuft Modell-Inference via Ollama/vLLM auf demselben Host, kommt diese Last hinzu.
Dify auf VPS mit Docker Compose produktionsnah deployen: Ressourcen, Worker, PostgreSQL/Redis, Storage, Domain, TLS, Backup und Upgrade.
CPU-Mindestbasis für die Dify-Docker-VM.
Basis für Plattformkomponenten, ohne lokale Modell-Inference.
Offizieller Quick Start nutzt Docker Compose.
DB-, Cache- und File/Object-Storage-Lifecycle separat schützen.
Web UI, API, Worker, Scheduler, DB, Redis und Sandbox haben unterschiedliche Fehlerbilder. State- und Netzwerkbedarf getrennt behandeln.
| Komponente | State | Kritisches Signal |
|---|---|---|
| Web/API | Weitgehend stateless | HTTP Health |
| Worker | Job-State extern | Queue-Lag |
| PostgreSQL | Persistent | Backup + Verbindung |
| Redis | Queue/Cache | Memory + Persistence-Modus |
Swap-Druck und volle Disk können wie Worker-Timeouts wirken. Baseline vor Deployment erfassen.
nprocfree -hdf -hTdocker versiondocker compose versionUpstream-Compose-Änderungen nicht blind per `git pull` in Production übernehmen; Diffs gegen `.env` und Overrides prüfen.
docker compose config > /tmp/dify-effective.ymldocker compose pulldocker compose psdocker compose logs --tail 120 api workerDB-, Redis-, Model-Provider- und App-Secrets können in einer Env-Datei liegen. Rechte, Rotation und Off-Host-Escrow kontrollieren.
stat -c "%a %U:%G %n" .envgrep -E "^[A-Z0-9_]+=" .env | cut -d= -f1 | sortKI-Antworten können lange dauern; Streaming-Verbindungen benötigen andere Timeouts als kurze HTTP-Requests.
Datenbank, Uploads/Object Storage und Konfiguration/Secrets können unterschiedliche Backup-Methoden brauchen. Ein einzelnes tar-Archiv ist nicht automatisch konsistent.
| Daten | Empfehlung |
|---|---|
| PostgreSQL | Konsistenter Dump/PITR |
| Uploads/Storage | Object-/Versioned-Backup |
| Config/Secrets | Verschlüsseltes Escrow |
Lange Mixed-Version-Phasen zwischen API und Worker können Queue-/Schema-Inkompatibilität erzeugen. Rollout an Release Notes ausrichten.
Auf Eka Sunucu VPS/GPU Dify Control Plane und Ollama/vLLM-Inference je Workload auf einem oder getrennten Servern planen.
Primärdokumentation und technische Referenzen dieses Leitfadens.
Mit passenden Infrastruktur- und Implementierungsleitfäden fortfahren.
Dify VPS
Es ist eine dokumentierte Docker-VM-Basis. Mehr RAM ist bei großen Datasets, Worker-Concurrency und lokaler Inference nötig.
Dify ist eine App-/Agent-Plattform, die Model-Provider/APIs nutzt. Lokale Inference kann separat via Ollama/vLLM bereitgestellt werden.
Bei kleinen Workloads ja, aber Plattform, DB und Inference teilen ggf. eine Fehlerdomäne. Backup und Ressourcenisolation entsprechend planen.
Mindestens PostgreSQL-Daten, Upload-/Storage-Inhalte und kritische Env-/Secret-Konfiguration wiederherstellbar sichern.