Dify is the most complete open-source platform for building LLM applications, and at over 138,000 GitHub stars it is also one of the most popular. In one self-hosted stack you get a visual workflow editor, a production-ready RAG pipeline, agent capabilities, model management across 100-plus providers, observability, and a built-in system to publish your app as a web app or API. The current release is 1.14.2 (May 19, 2026). Docker Compose gets the whole thing running, but Dify is a multi-service platform, not a single binary, so the friction is resources, upgrades, and deciding whether you actually need this much platform versus a lighter tool. This guide walks the install, connecting models, the problems people hit, and how Dify compares to Flowise, Langflow, and n8n.
Key takeaways
- Install is Docker Compose from the repo: clone,
cd docker, copy the env file,docker compose up -d, then open the web UI and create the admin account. - Plan for resources. The documented minimum is 2 vCPUs and 4 GB RAM; give it 8 GB and headroom for real use, because it runs several services (API, worker, web, database, Redis, and a vector store).
- It connects to 100+ model providers including OpenAI, Anthropic, Google, and local models via Ollama. You configure these in Settings, not in code.
- Upgrades require database migrations and, as of the 1.x line, reorganized environment variables. Back up before upgrading and follow the migration notes.
- RAG quality is a tuning job, not a default. Chunking, hybrid search, embeddings choice, and reranking all matter.
- If you only need a chatbot with retrieval, Dify may be more platform than you need; Flowise runs in a fraction of the RAM.
- Self-hosted Dify is free with no meaningful feature limits.
Install Dify with Docker Compose
Dify ships a ready Compose stack in its repository. You need Docker Engine 24.0 or newer and Docker Compose v2. Clone the repo, work inside the docker directory, copy the example environment file, and bring the stack up.
# Requirements: Docker Engine 24.0+ and Docker Compose v2
git clone https://github.com/langgenius/dify.git
cd dify/docker
# Copy the environment template and review it
cp .env.example .env
# Start the full stack (API, worker, web, db, redis, vector store)
docker compose up -d
# Check everything is healthy
docker compose psOnce the containers are healthy, open http://localhost (the web service listens on port 80 by default) and complete the one-time admin setup. For a production host, the practical minimum is 2 vCPUs, 4 GB RAM, and 40 GB of SSD, with more RAM if you expect concurrent users or large knowledge bases.
Connect your models
Dify is model-agnostic. Go to Settings, then Model Providers, and add credentials for any of 100-plus providers: OpenAI, Anthropic, Google, Azure, and many more. For private or no-cost inference, add a local model served by Ollama by pointing Dify at the Ollama endpoint. You can mix providers across an app, for example a strong hosted model for reasoning and a local embedding model for your knowledge base.
Build apps: chatflow, agent, workflow, and RAG
Dify gives you four app types. A Chatbot or Chatflow is a conversational app, optionally grounded in a knowledge base. An Agent can call tools to complete multi-step tasks. A Workflow is a visual, node-based pipeline for deterministic multi-step logic. The Knowledge feature is the RAG pipeline: upload documents, Dify chunks and embeds them, and your apps retrieve from them at query time. Every app can be published as a hosted web app or consumed through an API, which is what saves teams the weeks of glue code that a from-scratch build would cost.
1. Containers crash or the host runs out of RAM
What you see: services restart in a loop, the UI is unreachable, or docker compose ps shows unhealthy containers on a small VPS.
What it is: Dify is a multi-service stack. The 4 GB minimum is genuinely a minimum, and embedding large documents or serving several users pushes past it quickly.
The fix: give the host 8 GB or more, watch memory with docker stats, and if you do not need a feature (for example the sandbox for code execution) trim it from the Compose file. For larger deployments, move the database and vector store to managed services so the app containers are not competing for memory.
2. An upgrade breaks the stack
What you see: after pulling a new version, the app will not start, the database schema is out of date, or environment variables are no longer read.
What it is: Dify releases require database migrations, and the 1.x line reorganized the Docker environment variables (they now live under docker/envs/**). A blind git pull plus up -d can skip a required step.
The fix: back up your database and volumes first, read the release notes for the version you are moving to, reconcile your .env against the new template, and run the documented migration. Pin to a known-good tag and upgrade deliberately rather than tracking the main branch.
3. RAG answers are vague or miss the source
What you see: the knowledge base is loaded but answers are generic, cite the wrong passage, or miss obvious content.
What it is: retrieval quality is a function of how you ingest and search, and the defaults are a starting point, not an optimum.
The fix: tune the pipeline. Adjust chunk size and overlap to match your documents, enable hybrid search (keyword plus vector) rather than vector-only, choose an embedding model suited to your content, and turn on reranking so the best passages reach the model. Test retrieval with the built-in hit-testing before blaming the LLM.
4. Tool and model credentials feel exposed
What you see: you worry about who in a workspace can see or change API keys and tool credentials.
What it is: a legitimate multi-tenant concern that Dify has been hardening. The 1.14.2 release strengthened tenant isolation for sensitive endpoints and restricted tool credential updates to workspace admins and owners.
The fix: keep current on the 1.x line for these security fixes, scope workspace roles tightly so only admins manage credentials, and run Dify behind your own network controls. Self-hosting is the strongest answer here, since data and keys never leave your infrastructure.
5. It is too much platform for a simple chatbot
What you see: you wanted a document-grounded chatbot and ended up running a six-service stack.
What it is: Dify is a full application platform. That breadth is the value for real products, but overkill for a single narrow use case.
The fix: match the tool to the job. If your need is "chatbot with retrieval," Flowise is lighter and runs in around 1 GB of RAM. If your need is automation and orchestration with some AI steps, n8n fits better. Reach for Dify when you want the knowledge base, app publishing, team management, and observability together.
What is actually running: the Dify service stack
Understanding why Dify needs 4 GB of RAM is easier once you see what Compose starts. It is not one app but a small fleet of cooperating services: an API server, a background worker (Celery) for embeddings and async jobs, the web front end, a Postgres database, Redis for queues and caching, a vector store (Weaviate by default) for your knowledge bases, a sandbox for safely running code in workflows, an ssrf_proxy for safe outbound requests, and an nginx reverse proxy in front. When a container is unhealthy, knowing which one it is, with docker compose ps and docker compose logs <service>, turns a vague "Dify is down" into a five-minute fix.
Build a RAG app step by step
The knowledge base is Dify's signature feature, so here is the end-to-end flow. First, create a Knowledge, upload your documents, and choose how they are chunked; smaller chunks improve precision, larger ones preserve context, so match the size to your content. Pick an embedding model (a local one via Ollama keeps ingestion free and private). Enable hybrid search so retrieval uses both keyword and vector matching, and turn on reranking for better passage ordering. Then create a Chatflow or Agent app, attach the Knowledge as context, and use the built-in hit-testing tool to confirm the right passages come back for sample questions before you ship. Finally, publish the app as a hosted web app or an API endpoint. The whole loop is visual, which is exactly the engineering time Dify saves over wiring a retrieval pipeline yourself.
6. Dify cannot connect to Ollama or a local model
What you see: you add Ollama as a model provider but Dify reports a connection error, even though Ollama works on the host.
What it is: the same Docker networking trap that catches every container-to-host connection. From inside Dify's containers, localhost is the container, not your machine where Ollama listens.
The fix: make Ollama listen on all interfaces with OLLAMA_HOST=0.0.0.0:11434, then in Dify's model settings use http://host.docker.internal:11434 on Docker Desktop, or your host's LAN IP on Linux, as the base URL. See the Ollama setup guide for the host-side change.
Back up a Dify deployment
Dify's state lives in three places, and a real backup covers all of them: the Postgres database (apps, workflows, settings, accounts), the vector store data (your embedded knowledge bases), and the file storage volume (uploaded documents). Snapshot the Docker volumes on a schedule and dump Postgres, and before any version upgrade take a fresh backup, because Dify upgrades run schema migrations that are not designed to roll backward. Keep your reconciled .env alongside the backup so a restore lands on the same configuration.
Dify vs Flowise vs Langflow vs n8n (2026)
These four get compared constantly, but they solve different problems. Dify, Flowise, and Langflow are LLM app builders; n8n is an automation tool with AI nodes.
| Tool | Best for | Footprint | RAG | Notes |
|---|---|---|---|---|
| Dify | Full-stack LLM apps: RAG, agents, publishing, team management | Heavier (~4 GB+ multi-service) | Strong, production-ready hybrid search | Best default for most teams shipping AI products |
| Flowise | Chatbot with retrieval, fastest path to production | Light (~1 GB) | Strong, simpler | Pick when simplicity wins |
| Langflow | Visual multi-agent design on LangChain/LangGraph | Medium | Good | DataStax-backed visual IDE |
| n8n | Orchestration, scheduling, 400+ integrations with AI steps | Medium | Via larger automation flows | Choose when orchestration is the hard part |
What changed in Dify in 2026
- On the 1.x line with the current release 1.14.2 (May 19, 2026), which requires database migrations and reorganized Docker environment variables under
docker/envs/**. - Security hardening: stronger tenant isolation for sensitive endpoints and tool-credential updates restricted to workspace admins and owners.
- Reliability: restored tracing after workflow resumption and improved workflow callback tracking.
- Plugin system: the plugin daemon was upgraded, continuing Dify's move toward a pluggable, extensible platform.
Frequently asked questions
Is Dify free and open source?
Yes. Dify is open source and free to self-host, and the self-hosted edition has no meaningful feature limits. A paid cloud offering exists for teams that do not want to run infrastructure, but self-hosting gives you the full platform.
What are Dify's system requirements?
You need Docker Engine 24.0 or newer and Docker Compose v2. The documented production minimum is 2 vCPUs, 4 GB RAM, and 40 GB SSD. Because Dify runs several services, give it 8 GB or more for real workloads or concurrent users.
Dify vs Flowise: which should I choose?
Choose Dify for a full-stack AI application with a knowledge base, agents, app publishing, team management, and observability. Choose Flowise when you want the simplest, lightest path to a chatbot with retrieval; it runs in about 1 GB of RAM versus Dify's 4 GB minimum.
Can Dify use local models with Ollama?
Yes. In Settings, then Model Providers, add Ollama and point Dify at your Ollama endpoint to run fully local, no-per-token-cost inference. You can combine local and hosted providers within the same app. See the Ollama setup guide.
Is the self-hosted version of Dify limited?
No. The self-hosted edition has no meaningful feature limitations compared to the cloud version. The main trade-off is that you operate the infrastructure yourself, including upgrades, backups, and scaling.
Resources
- Dify Docker Compose Docs – official self-hosting guide
- Dify on GitHub – source, releases, and migration notes
- Ollama setup guide – run local models to power Dify
- n8n guide and CrewAI guide – orchestration and agent-framework companions
Last updated: June 13, 2026.
Josh writes about AI agents, local AI, and GEO, and runs nowservingto.com, a daily-fresh directory of Toronto's newest restaurants.