Self-hosting Dify — when it is worth it, and what it actually takes

The short version

• Evaluating only → cloud Sandbox (free, 200 message credits)
• Small production use → cloud Professional ($590/yr, 5,000 credits/mo)
• Documents cannot leave, or volume is high → self-host the open-source edition

1. What the cloud plans include

Note that Sandbox's 200 credits are a total, not a monthly allowance. Once spent, they do not refresh. Demoing around the company on a Sandbox account tends to stop mid-demo. Decide what the 200 calls are meant to prove before you start spending them.

2. When self-hosting is justified

The open-source edition runs under Docker with no licence fee. That does not make it right for everyone — there are really only two reasons to choose it.

First, the data cannot sit in an external cloud, because internal policy or a customer contract constrains where it is stored. That removes the cloud edition from consideration entirely. Second, volume: past roughly 10,000 messages a month, server cost works out below credit pricing.

Choosing self-hosting purely because it is free is expensive. Upgrades, backups, incident response and security patching become your job. $590 a year is better understood as the price of not doing those.

3. What you need in place

• A server that runs Docker and Docker Compose (a cloud VM is fine)
• Persistent volumes for the vector store and uploaded documents
• A reverse proxy and TLS certificate (simpler if access is internal only)
• An LLM API key — OpenAI, Anthropic or a model you run yourself
• A backup procedure covering both documents and the vector index

The API key is the line people miss. Dify itself may be free, but model usage is billed at cost. A document chatbot used five times a day by a hundred people is 15,000 calls a month; the per-call model price multiplied by 15,000 is a fixed monthly cost.

4. The shape of the setup

The official documentation has the accurate commands, so what follows is the sequence and the decisions attached to each step.

• 1. Provision a server and install Docker
• 2. Pull the official docker compose configuration and bring it up
• 3. Create the admin account and register the LLM API key
• 4. Load internal documents into the knowledge base and tune the chunk size
• 5. Create an app, set the prompt and point it at the knowledge base
• 6. Publish internally and configure access control

Step four decides quality more than anything else. Chunk too finely and context is lost; chunk too coarsely and unrelated passages get retrieved. Structured documents such as manuals work well split by heading; flowing documents such as meeting notes are easier at fixed length. This is a tuning loop against real questions, not a setting you get right first time.

5. Where operations go wrong

The most common failure is stale answers. Once documents are loaded, updating the source does not update the knowledge base. Without a refresh procedure owned by somebody, in six months you have a bot confidently reciting superseded policy.

The second is permissions. Load every company document into one knowledge base and answers will surface material the asker should not see. Separate knowledge bases and apps per department, or filter what goes in by audience.

Frequently asked questions