Dify on Your Own Server: Building AI Apps Without Much Code

Dify is an open-source platform for building LLM applications from a visual console: a chat assistant, an agent that uses tools, a multi-step workflow, or a text generator with a fixed template. What sets it apart from other flow builders is that it does not stop at drawing the flow. It gives you a complete operational product with a knowledge base where you upload PDF and Word files that get chunked and embedded automatically, a log of every conversation, a tool for correcting answers by hand, a ready API for each app with its own key, and team management with different roles. The short answer to "should I run it on my own server?" is yes if you have internal documents you do not want to upload to an outside service. Setup takes two commands after cloning the repository, the official minimum is 2 cores and 4GB of memory, and you connect it either to a local model through Ollama so no word leaves your server, or to a cloud model with an API key when you need higher quality. In a single working day you can launch an internal assistant that answers staff from the policies and procedures manual, cites its source in every answer, and keeps a log you review weekly to improve it.

Dify versus Langflow and Flowise

All three tools are open source and build AI apps with drag and drop, but each serves a different audience. Langflow and Flowise suit a developer who wants to draw a LangChain pipeline visually and call it as an API. Dify suits a whole team with a developer, a content owner and a manager who wants to see the logs, because it wraps the app in everything day-to-day operation needs.

Criterion	Dify	Langflow	Flowise
Knowledge base with file upload UI	Yes, with chunking and hybrid search	Through components you assemble	Through components you assemble
Conversation logs and answer correction	Built in	Limited	Limited
Members and roles	Owner, admin, editor, member	Basic	Basic
Ready chat UI for staff	Yes, a web link per app	Test playground	Embeddable widget
Minimum to run	2 vCPU / 4GB	1 vCPU / 2GB	1 vCPU / 2GB
Programmatic flexibility	Medium	High (Python)	High (Node.js)

If your goal is an internal tool used by 50 employees and managed by someone who does not code, Dify saves the most time. If you are building complex logic that will live inside your own product, Langflow or Flowise gives you more control, and both are available as ready templates in AI hosting.

A note on licensing: Dify ships under a license based on Apache 2.0 with two extra conditions, the main one being that you cannot run it as a multi-tenant service sold to other customers without a commercial license. Internal use inside your company is unrestricted.

Requirements in numbers

Dify runs as roughly ten containers: the frontend, the API server, a background worker for file processing, PostgreSQL, Redis, a vector database (Weaviate by default, replaceable with pgvector or Qdrant), a code execution sandbox, an SSRF proxy, the plugin daemon and Nginx. Idle memory use is about 2.5GB and climbs while large files are being indexed.

Scenario	Specs	Plan	Annual incl. VAT
Dify with a cloud model, up to 30 users	2 vCPU / 4GB	Numuw	6,900 SAR
Dify with a cloud model and a large knowledge base	4 vCPU / 8GB	Business	11,500 SAR
Dify with a local 8B model via Ollama	8 vCPU / 24GB	Enterprise + 4 RAM add-ons	20,400 SAR

The last row works out as the Enterprise plan at 18,000 SAR plus 8GB of extra memory through four add-ons at 600 SAR each, which is 2,400 SAR. An 8-billion-parameter model quantized to 4 bits needs about 5 to 6GB of memory and generates roughly 5 to 10 tokens per second on 8 CPU cores, which is acceptable for an internal assistant answering in a short paragraph.

Up and running in ten minutes

On a cloud server running Ubuntu with Docker installed:

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
# change SECRET_KEY and the database and Redis passwords
sed -i "s|^SECRET_KEY=.*|SECRET_KEY=$(openssl rand -base64 42)|" .env
docker compose up -d
docker compose ps

Open the server address in a browser at /install to create the owner account. Right after that, put an external Nginx with an SSL certificate in front of the internal port 80, or change the container port and bind it to 127.0.0.1. Never leave the console exposed without HTTPS, since it holds the API keys for your models.

Connecting a model: local or cloud

Local model through Ollama

Install Ollama on the same server and pull a model with good Arabic support, such as a 7B or 8B Qwen, then make Ollama listen on the internal Docker network address rather than every interface:

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen2.5:7b
sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=172.17.0.1:11434"
sudo systemctl restart ollama

In Dify settings, open model providers and add Ollama with the address http://172.17.0.1:11434 and the model name. Add a local embedding model such as bge-m3 too, so document indexing stays on the server.

Cloud model

When you need better writing or reasoning, add a cloud provider with an API key. Be clear about what leaves the server: the question and the retrieved chunks go to the provider, while full documents and the vector index stay with you. A practical middle ground is a local model for questions that touch personal data or contracts and a cloud model for general drafting.

Team permissions

Dify organizes users in a workspace with roles. The owner controls everything including billing and members, the admin manages members and models, the editor builds and edits apps, and the member only uses published apps. The rule of thumb is one owner, two admins at most, editors only for people who actually build, and everyone else as members. Cloud model keys are added once at the workspace level, so editors never need to see them. End users do not need a console account at all, since they open the published web app link, which you can protect with company sign-in or restrict to the office network through Nginx.

Example: an assistant that answers from company policy

1. Create a knowledge base called "Policies" and upload the HR manual, the procurement regulations and the information security policy. Choose automatic chunking at about 500 tokens with 50 overlap, and hybrid search (vector plus keyword), because article and clause numbers need exact matching.
2. Create a Chatflow app and connect the retrieval node to the "Policies" knowledge base, returning the top 5 chunks.
3. Write the system prompt: "Answer in Arabic using only the attached chunks, cite the document name and article number, and if there is no explicit text, say so and refer the employee to HR."
4. Turn on source citations and publish the app as an internal web link.
5. After a week, open the logs and correct wrong answers through the annotation feature, which Dify then uses as reference answers when the question comes up again.

In practice, an assistant like this covers most questions about leave, business travel allowances and spending limits, and takes dozens of repeated queries off the HR team every week.

An API for every app

Every app you publish in Dify automatically gets a REST API with its own key, so you can call the same assistant from your ERP or an internal bot without rebuilding it. The call is simple:

curl -X POST https://dify.example.sa/v1/chat-messages   -H "Authorization: Bearer app-xxxxxxxx"   -H "Content-Type: application/json"   -d '{"inputs": {}, "query": "How many days of emergency leave do I get?",
       "user": "emp-1042", "response_mode": "blocking"}'

The user field ties the conversation to the employee in the logs, so you know later who asked what and what they were told. Give each calling system its own key, so you can revoke one when needed without stopping the other integrations.

Day-to-day operations: updates and backups

The Dify team ships updates about every two weeks, and some of them change the database schema. Do not update production blindly. Back up the entire volumes directory and the .env file, check out the specific release tag with git, then run docker compose pull followed by up -d. Three things belong in your daily backup: the PostgreSQL database holding apps and conversations, the storage directory holding uploaded files, and the vector database data. The daily backup add-on costs 800 SAR per year with 7-day retention or 2,000 SAR with 30 days, and it covers the whole server if an update fails and you need yesterday's state back.

The decision

If your documents are sensitive and your team includes non-developers, run Dify on a server in Riyadh with roughly 8ms latency from your offices. Start with the Numuw plan and a cloud model to prove the idea within two weeks, then move to a local model once the value is clear. Check pricing and plans to choose the right size.