Dify

Dify is an open-source LLMOps platform that combines a visual workflow builder, a built-in RAG engine, and a prompt IDE into a single self-hostable product. You can go from a blank canvas to a published AI application, complete with retrieval-augmented generation and tool use, without writing backend code. The cloud tier removes infrastructure overhead; the Docker-based self-host keeps data on your own servers.

When people say they want to "build an AI app," what they usually mean is: connect my documents to an LLM, let it answer questions, and deploy something a non-engineer can use. Dify does exactly that, and it does it without asking you to write backend code. That's a specific promise, and Dify largely keeps it.

I've watched a lot of no-code AI tools come and go, and the usual failure mode is the same: they're great for demos and fall apart the moment you need something real. Dify is different. It's sitting at roughly 91,000 GitHub stars, it's actively maintained with multiple releases per month, and real organizations run production systems on it. The gap between "platform for demos" and "platform for production" is narrower here than anywhere else in the visual LLM builder space.

What Dify is and what it isn't

Dify is an LLMOps platform. That term gets used loosely, but in Dify's case it means a specific set of things: a workspace where you design AI applications, a runtime that runs them, a RAG engine that connects your documents, and tooling to monitor and improve output quality over time.

It is not a code framework. You don't install a Python package and write agent logic. The primary interface is a browser-based canvas where you drag nodes onto a workflow, connect them, configure prompts, and publish. The underlying code runs on Dify's backend, whether that's their cloud or your self-hosted instance.

That distinction matters because it shapes who Dify is for. Product managers, operations teams, and developers who want to ship something fast benefit enormously from this model. Engineers who need fine-grained control over agent behavior, custom tool implementations, or complex orchestration logic will eventually hit walls that require dropping into Dify's API or Python plugins.

The project started in 2023 and grew quickly. The GitHub repo at github.com/langgenius/dify crossed 90,000 stars by mid-2026, which puts it in the top tier of AI open-source projects by community interest. That star count reflects both genuine adoption and the fact that Dify hit a real gap: a self-hostable, production-capable alternative to building everything from scratch.

Architecture: how it actually works

Dify runs as a multi-service stack. The frontend is a Next.js application. The backend API is a Python FastAPI service. Data lives in PostgreSQL. Vector embeddings live in a pluggable vector store (Weaviate by default, with options for Qdrant, Milvus, and others). Redis handles caching and task queues.

When you build a workflow in the editor, you're creating a directed acyclic graph stored in the database. When a user hits your published endpoint or web app, Dify's backend traverses that graph, calls LLM APIs at each LLM node, runs tools at tool nodes, handles branching at condition nodes, and streams the result back to the user.

The architecture is not exotic, but it's solid. Docker Compose bundles everything into a single deployment unit that works on a modestly sized VPS. For teams that need to scale, Kubernetes Helm charts handle multi-replica deployments with shared PostgreSQL and Redis.

The workflow builder

This is the core of the product. The workflow canvas gives you a palette of node types:

• LLM node: calls a model with a prompt template, takes input variables, produces output
• Retrieval node: queries a knowledge base (your RAG dataset) with a search query
• Tool node: calls an external API or built-in tool (web search, code execution, image generation)
• Condition node: branches the flow based on a value or expression
• Iteration node: loops over a list, running a subgraph for each item
• Variable aggregator: merges outputs from parallel branches
• Answer node: sends the final response to the user

Connecting nodes passes variables from one output to the next input. You reference variables with double-brace syntax: {{node_id.output_variable}}. The workflow engine resolves these at runtime.

Honestly, the builder is intuitive. For someone who can think in flowcharts, the mental model transfers immediately. The friction appears at scale: once a workflow has 20+ nodes, tracing variable references becomes tedious. There's no visual variable inspector that shows you where a given variable is used across the entire flow. That's a real UX gap for complex workflows.

RAG pipeline

Dify's knowledge base feature is where it earns a lot of its production credibility. The RAG setup is a first-class workflow, not an afterthought:

1. Upload documents (PDF, Word, Markdown, web scraping, Notion sync, GitHub sync)
2. Choose chunking strategy (automatic, fixed-size, paragraph-based, parent-child)
3. Select an embedding model (OpenAI, Cohere, local via Ollama)
4. Configure retrieval settings (top-K, similarity threshold, reranking model)
5. Test retrieval quality against real queries before connecting it to a workflow

That last step is underrated. Most frameworks give you a RAG pipeline, but few give you an interactive testing interface to see exactly what chunks are being retrieved for a query and why. Dify does. You can inspect retrieved chunks, adjust settings, and iterate until retrieval quality is good before wiring it into your production workflow.

The retrieval augmentation step also supports hybrid search (keyword + semantic) and reranking with models like Cohere Rerank or a local cross-encoder. For teams where retrieval quality is the difference between a useful and useless application, these knobs matter.

Agents inside Dify

Dify has two application types: Chatbot/Completion (simpler, one LLM with tools) and Workflow (the full visual builder). For agent-style behavior, the Agent node in workflows lets you define a set of tools, give the LLM a system prompt, and let it decide which tools to call and in what order.

It's not as expressive as frameworks like CrewAI or AutoGen where you define multiple collaborating agents with distinct roles. Dify's agent model is more like a single capable agent with access to tools, embedded inside a larger workflow. That's sufficient for a lot of use cases, but if you're building a system where five agents debate and delegate tasks to each other, Dify is not the right tool.

The tool library includes web search (Bing, Google via SerpAPI), code execution (in a sandboxed Python environment), DALL-E image generation, Wikipedia, and a growing plugin marketplace. Community plugins extend this significantly, but quality varies enough that you should test any community plugin carefully before putting it in production.

Pricing in practice

Self-hosting is where Dify's economics shine. Apache 2.0 means you can run it on your own infrastructure, with your own LLM API keys, at zero platform cost. Your only expenses are the VPS (or Kubernetes cluster) and the LLM API calls you make. For an internal knowledge search tool used by 50 employees, self-hosting a $20/month VPS and paying for LLM API calls directly is dramatically cheaper than most SaaS alternatives.

Dify Cloud makes sense when you don't want to manage infrastructure. The free Sandbox tier gives you enough to evaluate the platform. At $59/month for Professional, you get higher usage limits and basic collaboration. The Team tier at $159/month adds SAML SSO and audit logging, which most organizations will need for anything beyond internal tools.

Enterprise pricing is not published. If you need enterprise features at scale, expect a negotiation.

Getting started

Self-hosted setup:

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
# Edit .env: add your OPENAI_API_KEY or other provider keys
docker compose up -d

The UI is at http://localhost. First-time setup walks you through creating an admin account and connecting your first LLM provider. From there you can create a Knowledge Base, upload a PDF, and have a working RAG chatbot in about 20 minutes.

For cloud, sign up at dify.ai, add a model provider in Settings, create a Knowledge Base, and build a workflow. No local installation needed.

Dify vs the alternatives

Dify vs Langflow

Langflow is a visual builder specifically for LangChain flows. Dify is a more complete LLMOps product. Dify has a more polished UI, built-in RAG with retrieval quality testing, prompt versioning, and a publishable end-user interface. Langflow gives you direct access to the entire LangChain component library, which is useful if you're already invested in that ecosystem. For most teams starting fresh, Dify is the better default because the production tooling is further along.

Dify vs Flowise

Both are self-hostable visual builders. Dify has a larger team, faster development pace, and more built-in features (especially RAG and the application publishing layer). Flowise is simpler to understand but less capable for production deployments. If Dify's complexity feels like too much, Flowise is a reasonable step-down option.

Dify vs LangChain

LangChain gives you a code framework. Dify gives you a visual platform. These are not the same thing. LangChain is more flexible for engineers who need custom behavior. Dify is faster for teams that want to ship an application without writing backend code. The two are not mutually exclusive: Dify exposes an API and supports custom code nodes, so sophisticated teams sometimes use LangChain to build components and Dify to orchestrate them.

Where Dify falls short

The visual editor doesn't scale to very complex workflows. When you have 30+ nodes with many variable connections, the canvas becomes hard to read and there's no way to search for where a specific variable is used.

Debugging is limited. When a workflow run fails or produces unexpected output, the run history shows you inputs and outputs at each node, which helps. But there's no step-through debugger and no way to inspect intermediate state at an arbitrary point in the graph.

Custom integrations require Python. Dify's plugin system lets you write custom tools in Python, but that's a step up in complexity from the visual editor. If your use case needs a tool that isn't in the built-in library and isn't covered by a community plugin, you're writing code.

The upgrade path for self-hosted instances is manual. New releases require pulling updated Docker images and sometimes running database migrations. It works, but it's not as smooth as a managed upgrade.

Who should use Dify

Dify is the right call for teams that want a production-capable LLM application platform without building infrastructure from scratch. Product and operations teams who can't write Python backends but need to ship real tools to real users will find it genuinely empowering. Engineering teams that want to prototype fast and hand something to stakeholders without writing a full backend will get a lot of value from it.

It's a less good fit for teams building complex multi-agent systems, teams that need highly customized orchestration logic, or teams that are already comfortable with LangChain or LangGraph and don't want to switch mental models.

The 91,000 GitHub stars and the frequency of production deployments in the community are meaningful signals. Dify has crossed the threshold from "promising project" to "mature platform." That's rare in this space, and it's the main reason to take it seriously.

Key features

• Visual drag-and-drop workflow builder for chaining LLM steps, tools, and conditionals
• Built-in RAG pipeline with document indexing, chunking, and retrieval tuning
• Agent node with tool calling, iteration loops, and variable passing
• Multi-model support: OpenAI, Anthropic, Azure, Gemini, Hugging Face, Ollama and more
• Prompt engineering IDE with version history and A/B testing
• One-click publish to web app, API endpoint, or embed widget
• Annotation-based output quality review and human feedback collection