Turkey (Turkish)
Germany (German)
Worldwide (English)
Minimum CPU starting point for the Dify Docker VM.
Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
A self-hosted Dify deployment is more than web/API: workers, database, Redis, sandbox and storage cooperate. “Containers are up” is not sufficient evidence of production health.
Do not interpret Dify’s baseline memory as “Dify plus local model.” Local inference adds CPU/GPU VRAM and system RAM requirements; size platform and inference separately.
Current Dify self-host documentation gives a Docker VM baseline of at least 2 vCPU and 8 GiB memory. If model inference runs on the same host through Ollama/vLLM, add that workload on top.
Current Dify self-host documentation gives a Docker VM baseline of at least 2 vCPU and 8 GiB memory. If model inference runs on the same host through Ollama/vLLM, add that workload on top.
Deploy Dify on a VPS with Docker Compose using a production-oriented design for resources, workers, PostgreSQL/Redis, storage, domain, TLS, backups and upgrades.
Minimum CPU starting point for the Dify Docker VM.
Baseline for platform components, excluding local model inference.
The official quick start uses Docker Compose.
Database, cache and file/object storage lifecycles need separate protection.
Web UI, API, workers, scheduler, database, Redis and sandbox have different failure modes. Separate state and network requirements.
| Component | State | Critical signal |
|---|---|---|
| Web/API | Mostly stateless | HTTP health |
| Worker | Job state external | Queue lag |
| PostgreSQL | Persistent | Backup + connection |
| Redis | Queue/cache | Memory + persistence mode |
Swap pressure and disk exhaustion can surface as worker timeouts or secondary failures. Record the baseline before deployment.
nprocfree -hdf -hTdocker versiondocker compose versionInstead of blindly pulling upstream Compose changes into production, review diffs against your `.env` and overrides.
docker compose config > /tmp/dify-effective.ymldocker compose pulldocker compose psdocker compose logs --tail 120 api workerDatabase, Redis, model-provider and application secrets can coexist in one environment file. Control permissions, rotation and off-host escrow.
stat -c "%a %U:%G %n" .envgrep -E "^[A-Z0-9_]+=" .env | cut -d= -f1 | sortAI responses can be long-lived; streaming connections need different timeout behavior from short HTTP requests.
Database, uploaded files/object storage and configuration/secrets may need different backup methods. One tar archive is not automatically a consistent backup.
| Data | Recommendation |
|---|---|
| PostgreSQL | Consistent dump/PITR |
| Uploads/storage | Object/versioned backup |
| Config/secrets | Encrypted escrow |
Long mixed-version windows between API and workers can expose queue or schema incompatibilities. Match rollout behavior to release notes.
On Eka Sunucu VPS/GPU infrastructure, plan the Dify control plane and Ollama/vLLM inference on one or separate servers according to workload.
Primary documentation and technical references used by this guide.
Continue with related infrastructure and implementation guides.
Dify VPS
It is a documented Docker VM baseline. More is needed as datasets, worker concurrency and local inference grow.
Dify is an application/agent platform that connects to model providers/APIs. Local inference can be supplied by Ollama/vLLM separately.
For small workloads yes, but platform, database and inference may share one failure domain. Design backups and resource isolation accordingly.
At minimum keep recoverable copies of PostgreSQL data, uploaded/storage content and critical environment/secrets configuration.