Dify

Last reviewed Aug 26, 2026 · 818 words

A default Dify install runs about nine containers — API server, background worker, web frontend, Postgres, Redis, an nginx gateway, a code-execution sandbox, an SSRF proxy, and a Weaviate vector database. I lead with that number because it is the honest signal of what Dify is: not a lightweight tool you add to a box, but a platform you operate. In exchange you get the most complete open-source answer to "we want to build LLM apps as a team" — visual workflows, a built-in RAG engine, agents, prompt management, and usage observability under one Apache-2.0 roof, which is why it sits at 153,000 stars barely three years after first release.

The RAG engine is the part that saves real weeks

Most teams arrive at Dify for the workflow builder and stay for the knowledge pipeline. Upload documents or point it at sources, and Dify handles chunking, embedding, indexing into the bundled vector store, and retrieval with configurable strategies — the plumbing that otherwise becomes a thousand lines of glue code and three infrastructure decisions. It will not beat a hand-tuned pipeline on a hard corpus, and heavy users eventually want control over chunking that a UI can't fully express, but for the standard case — internal docs, support knowledge, product manuals feeding a chatbot — it collapses weeks into an afternoon. Whether retrieval is even the right tool for your problem is a separate question; RAG vs fine-tuning covers that fork.

Workflows, agents, and the difference from a canvas tool

Dify's visual builder chains LLM calls, conditionals, code nodes, HTTP requests, and tool-using agent steps into applications you then publish — as a hosted chat UI, an embeddable widget, or an API with per-app keys. That last step is the philosophical difference from lighter canvas tools like Langflow: Dify assumes the flow is destined to become an application with users, logs, and a lifecycle, and builds the surrounding scaffolding — versioned prompts, datasets, annotations, monitoring — into the product. If you want a sketchpad, that scaffolding is overhead; if you want to ship something your support team will use daily, it is exactly the part you'd otherwise build yourself. The head-to-head is in Dify vs Langflow.

Budget 8 GB of RAM, whatever the minimum says

The catalogue lists a 4 GB minimum and the official install path is cp .env.example .env && docker compose up -d from the repo's docker directory, with the web UI landing on port 80. Both facts are true and both flatter the experience. Postgres, Redis, Weaviate, and the API stack idle politely, but index a few thousand documents while a workflow runs and 4 GB becomes swap-adjacent. A box with 8 GB and 2-4 cores makes Dify boring to operate; 4 GB makes it an occasional mystery. The .env file is long but the defaults are sane — the settings worth changing early are the secret key, the exposed port, and the storage backend if you want uploads on S3-compatible storage rather than a local volume. Helm charts exist for Kubernetes shops, and multi-user support with workspace roles is in the free edition, which is more than some rivals offer.

Where the open-source edition stops

Dify's core is Apache-2.0 and genuinely usable alone, but the company reserves features for paid tiers — enterprise concerns like SSO integration and advanced workspace controls sit behind commercial licensing, and the ceiling moves over time, so check the current matrix before promising your security team anything. There are also brand-related usage restrictions on the free edition (multi-tenant SaaS resale is the thing being fenced off). For a team building internal tools, none of this bites. For a company reselling Dify-powered apps, read the licensing page first.

Local models plug in cleanly

Every model touchpoint — LLM, embeddings, reranking — is provider-configurable, and pointing Dify at Ollama or any OpenAI-compatible endpoint on your network takes a settings-page minute. A fully local stack (Dify plus a GPU box serving models) is a realistic private deployment: documents, embeddings, and completions never leave your network, which for some teams is the entire reason to self-host this category at all.

What I'd do

If you're a team of two or more shipping LLM apps to actual users, self-host Dify on an 8 GB VM, wire it to Ollama for cheap iteration plus one commercial API for quality-critical paths, and let the built-in RAG engine carry your first three applications. Keep the stack updated monthly and snapshot Postgres before upgrades. If you're one person exploring pipeline ideas, start with Langflow instead and graduate to Dify when the words "can the support team use this" enter the conversation — that sentence is Dify's actual system requirement.