← All notes Self-hosting · Dify

Self-hosting Dify in 2026: what the quickstart doesn't tell you

Dify's docker compose up genuinely works — ten minutes and you have the console running. Then reality starts. Here's what I wish someone had written down before my first deployment.

Sizing reality

The compose stack runs around six services (API, worker, web, Postgres, Redis, sandbox). Idle it's light; the moment several people hit "run" on LLM workflows simultaneously, the worker becomes your bottleneck. For a small team, plan 4GB RAM minimum beyond your OS — 8GB if you enable local embedding models.

The upgrade train is real

Dify ships constantly. That's good for features, stressful for operators: DSL versions move too. A workflow exported from 1.15 may warn on 1.16 import (DSL 0.6.0 vs 0.7.0). Two habits make this painless:

Model configuration is where beginners lose a day

Templates and workflows reference models as provider/name pairs. If your workspace has no credential configured for that provider, imports succeed and runs fail. Before importing anything: Settings → Model Provider → configure at least one OpenAI-compatible endpoint. Note the exact provider path shown in the node UI — it must match what templates reference (e.g. langgenius/openai/openai).

DSL imports: the safety checklist

When self-host vs cloud flips

Under ~5 active builders and data-sensitivity requirements, self-hosting wins clearly. If nobody on your team wants upgrade duty, cloud's $59 tier is cheaper than one missed weekend patch. Hybrid is common: cloud for experiments, self-hosted for the workflows touching private data.

Faster start: Dify Content Engine gives you 8 schema-validated DSL 0.7.0 templates — multi-platform post generation, SEO blueprints, localization, comment triage, an anti-hallucination trend agent — so day one is importing value instead of dragging nodes.