Dify

If Coze is the "zero-code fast lane" ByteDance built by stacking its traffic ecosystem, Dify walked nearly the opposite direction: a startup that, on the strength of one Apache 2.0 (with additional terms) open-source repo, grew into one of the loudest community voices among global LLM application platforms. By mid-2026, Dify's GitHub stars had passed 140K (~134.7K in April 2026, entering GitHub's global top 50); at one point its star count exceeded LangChain itself, and it squeezed into GitHub's global Top 100 repos.

This page dissects Dify as an "agent platform case": what it can and cannot do, how it organizes code and runtime internally, and which scenarios call for it and which should route around it.

1. Positioning: An Open-Source LLM Application Development Platform

Dify is developed by Suzhou Yuling Artificial Intelligence Technology Co., Ltd. (publicly branded LangGenius / Dify.AI). The company was founded in 2023 and open-sourced its first version that May. The official self-positioning has drifted noticeably:

• Early (2023–2024): an "open-source LLMOps platform," benchmarking LangChain's "productized wrapper," with visual prompt orchestration + RAG + log operations as the selling points.
• Now (2025–2026): a "platform for production-ready agentic workflows." The homepage tagline has become "The Platform for Production-Ready Agentic Workflows"; Agent and Workflow are first-class citizens, with LLMOps demoted to an underlying capability.

A few key milestones (all from the official blog and public reporting):

Date	Event
2023-05	First open-source release; over 4,000 apps created within a week
2025-02	v1.0.0 ships; the plugin system (Plugin Daemon) lands, with tools/models/agent strategies all pluginized
2025-06	GitHub stars pass 100K
2025-07	v1.6.0 ships built-in two-way MCP support
2025-09	Knowledge Pipeline launches (a visual RAG data-processing pipeline)
2026-03	Closes a $30M Pre-A round led by Sequoia China, at a ~$180M post-money valuation
2026-03	Passes SOC 2 Type II, ISO 27001, and GDPR compliance audits for the second consecutive year
2026-05	Version iterates to v1.14.x; Creator Center and template marketplace launch

How to Understand Dify's Ecological Niche

Dify is not an agent framework; it is "the finished house built on the framework." LangGraph gives you a graph-orchestration SDK and you write the code, manage state, and build services yourself; Dify turns graph orchestration into a canvas and builds in serving, auth, logging, RAG, and the model gateway. The price is accepting its abstractions and runtime. The first-principles question of selection is always: do you want "the freedom of writing code" or "the speed of not writing code"? See the framework selection overview.

2. Core Capabilities

2.1 Application Types and Workflow Orchestration

"Applications" in Dify come in several forms:

• Chatbot / conversational apps: the classic chat interface, with session variables, openers, and annotated replies.
• Agent apps: single-agent applications centered on autonomous LLM decision-making (see Section 3).
• Chatflow: a conversational workflow with memory, for multi-turn scenarios.
• Workflow: stateless batch/automation flows, one input one output, usually triggered via API or Triggers.
• Text Generator: the simplest single-turn text generation, being absorbed into Workflow.

The Workflow canvas is Dify's heart. Node types fall roughly into four classes:

┌─ Input control ──┐  ┌─ Reasoning ─────┐  ┌─ Data/tools ─────┐  ┌─ Flow control ──┐
  Start               LLM                 Knowledge             IF/ELSE
  Variable            Agent node          Retrieval            Iteration
  aggregator          Code execution      Tool node            Loop
  End/Answer          Template            HTTP request         Parallel branches
  Human Input         transform           Variable assignment  Triggers
  (v1.13+)            Parameter extractor

Notable evolution in the past two years:

• v1.8 (summer 2025): automatic canvas layout, OAuth integration, execution performance improvements.
• v1.9 (fall 2025): the execution engine rewritten as a queue-based graph engine, with markedly improved concurrency and fault tolerance for long flows.
• Triggers (2025-11): workflows no longer sit passively waiting for API calls; three trigger types are supported—Schedule, Webhook, and plugin events—and Dify starts covering "unattended automation."
• v1.13 (2026-03): the Human Input node—workflows can pause until a human approves/edits/reassigns and then continue. This makes Human-in-the-Loop a native node instead of users hacking it with external callbacks.

2.2 The RAG Engine and Knowledge Pipeline

RAG is Dify's traditional strength; its capability list basically covers the mainstream techniques of engineering practice:

• Multiple indexing modes (high-quality/economy), parent-child chunk retrieval (introduced in v0.15), hybrid retrieval (vector + full-text) + rerank, and metadata filtering (v1.1).
• External vector stores supported: Weaviate, Qdrant, Milvus, pgvector, TiDB Vector, and a dozen more.
• Multimodal knowledge bases launched in January 2026, unifying text and images into one semantic space.
• Knowledge Pipeline (2025-09, v1.9): the previously black-box chain of "documents in → clean → chunk → vectorize → store" also became a visual pipeline; data sources, document processing, and vector optimization stages are all pluginized, and the official team is building a partner ecosystem around it.

Why Knowledge Pipeline Matters

Traditional Dify knowledge bases were "upload documents, leave the rest to the platform"—which in enterprise scenarios is exactly where things most often go wrong: bad PDF table parsing, mismatched chunking strategies, internal data sources that need connecting. Knowledge Pipeline opens this chain into an orchestrable DAG, meaning ETL logic can be customized per business. If your RAG problem is retrieval quality, what you should troubleshoot first is often this pipeline rather than the retrieval parameters; see the troubleshooting approach on the RAG component page.

2.3 The Plugin System

v1.0 was a watershed in Dify's architecture: model providers, tools, agent strategies, and extensions (Endpoints) were all stripped out of the main repo's code into plugins running in a standalone Plugin Daemon, distributed via the Dify Marketplace. Plugins are developed with the Python SDK, supporting local debugging before packaging into .difypkg.

Two practical effects:

• The ecosystem snowballs: tool plugin counts grow fast; Brave Search, Tavily, Firecrawl, Slack, Feishu, DingTalk, and more all have official or community plugins; third-party SaaS (Bright Data, MongoDB Atlas, Agora, etc.) list themselves proactively.
• Cleaner self-hosting: model and tool version upgrades no longer require upgrading the whole Dify main program; enterprises can develop private plugins without publishing them.

2.4 Model Provider Aggregation and API Publishing

Dify ships with connections to mainstream model providers (OpenAI, Anthropic, Gemini, xAI, DeepSeek, Qwen, Zhipu, Ollama local models, etc., maintained as plugins), and the same application can switch underlying models at any time for comparison. This "model gateway" capability paired with usage logs is naturally suited to multi-model cost governance, and maps directly onto the methodology in the cost optimization page.

Once an application is built, Dify offers four delivery forms:

1. WebApp: generates a shareable web app directly, embeddable via iframe.
2. Service API: REST APIs (/v1/chat-messages, /v1/workflows/run, etc.)—the main path for production integration.
3. Publish as a tool: a Workflow can be published as a tool for other agent applications to call—workflow-as-tool is Dify's main means of "multi-agent-like" collaboration.
4. Publish as an MCP server (v1.6+): expose the entire Dify application to any MCP client.

import requests

# Call a published Dify conversational app (the Service API shape has stayed stable for years)
resp = requests.post(
    "https://api.dify.ai/v1/chat-messages",   # swap in your own domain when self-hosting
    headers={"Authorization": "Bearer app-xxxxxxxx"},  # app-level API key
    json={
        "inputs": {},                          # input variables defined in the app's orchestration
        "query": "Summarize these meeting minutes for me",
        "response_mode": "streaming",          # or "blocking"
        "user": "user-001",                    # end-user identifier for session and log isolation
    },
    stream=True,
)
for line in resp.iter_lines():
    if line:
        print(line.decode("utf-8"))

3. Agent Capabilities: More Restrained Than They Look

3.1 Agent Strategies: Function Call and ReAct

Dify's agent is not a hard-coded loop but pluggable "agent strategies":

• In classic agent apps, two strategies are built in: Function Calling and ReAct—the former relies on the model's native tool-calling capability; the latter uses a Thought/Action/Observation text protocol to support models without function calling (the underlying ideas: the ReAct paper deep read and Agent Loop).
• After v1.0, agent strategies are themselves plugins; the community can build and list its own reasoning strategies (for example, strategy plugins supporting MCP tool discovery).
• The Agent node (introduced 2025-03) puts the agent inside the workflow: when a step in the flow needs autonomous decisions, attach an Agent node, pick the strategy and toolset, and the LLM autonomously runs multiple rounds of tool calls inside that node, handing results back to the deterministic flow when done. This is the pragmatic combination of "deterministic flow + local autonomy," far more dependable than a fully autonomous agent.

3.2 The Tool Ecosystem and MCP Today

Dify applications can call four classes of tools: marketplace plugin tools, custom OpenAPI tools (just paste an OpenAPI schema), workflows published as tools, and MCP servers.

MCP support is the "two-way" capability that landed in v1.6.0 (2025-07):

• As an MCP host: configure any MCP server (SSE / Streamable HTTP transports), and its tools automatically appear in the tool lists of agents and workflows.
• As an MCP server: expose a Dify application in reverse as an MCP endpoint, letting MCP clients like Claude Code and Cursor call your Dify app directly.

With this, Dify is basically complete on the tools & MCP line. But stay clear-eyed: once MCP tools enter Dify, they remain subject to the Dify runtime's constraints (auth, timeouts, auditing all at the platform layer)—which is the control enterprises want, but it also means you can't directly transplant the local-IDE-oriented usage patterns of the MCP ecosystem.

Dify Agent's Ceiling

Dify's agent capability is positioned as "sufficient," not "ultimate." It lacks LangGraph's fine-grained state-machine control and the Claude Agent SDK's execution loop deeply coupled to a coding environment. For scenarios needing complex multi-agent interplay, long-horizon state management, or fine-grained checkpoints, use a code framework (see LangGraph and Multi-Agent Architecture) and treat Dify as the delivery and operations layer, rather than straining to simulate framework capabilities in the canvas.

4. Self-Hosting and the Enterprise Edition

Dify's business model dictates that the self-hosting experience must be good—and it is: after git clone, enter the docker/ directory, cp .env.example .env, and one docker compose up -d brings up the full environment. The Compose stack's containers are roughly:

nginx (gateway) → web (Next.js frontend)
                ↘ api (Flask backend)
                ↘ worker (Celery async tasks: index building, batch jobs)
                ↘ plugin_daemon (plugin runtime)
                ↘ sandbox (code execution sandbox, DifySandbox)
                ↘ ssrf_proxy (SSRF protection proxy for outbound requests)
Infrastructure: PostgreSQL / Redis / vector store (Weaviate by default, swappable)

For production, official Helm Charts support deployment to Kubernetes. The resource bar is not high (official recommendation starts at 2C4G), but to seriously carry production traffic, Celery worker counts, vector store specs, and PostgreSQL all need capacity planning.

The difference between Community and Enterprise editions is mainly in the governance layer:

Capability	Community (open source)	Enterprise
Core orchestration / RAG / plugins	All available	All available
Workspaces	Single	Multi-workspace + enterprise management
SSO / audit logs	No	Yes
Commercial licensing	Additional-terms limits (multi-tenant SaaS resale restricted)	Commercial license
SLA / official support	Community	Yes
Deployment	Docker / K8s self-hosted	Self-hosted / VPC / cloud marketplaces (listed on AWS and Azure Marketplace)

The Enterprise edition has real big-customer endorsements: Japan's Kakaku.com used Dify Enterprise to have 75% of its employees create nearly 950 internal AI applications—a case worth remembering, showing that Dify Enterprise's main battlefield is "company-wide platform rollout," not a single high-tech team.

5. Architecture at a Glance

The Dify main repo is a typical big-tech-grade monorepo with a clear code structure—well suited as a full-stack reference project to read:

dify/
├── api/                  # Python backend (Flask + SQLAlchemy + Celery)
│   ├── core/             # core domain logic: rag, workflow, agent, model_runtime
│   ├── services/         # application service layer
│   └── ...
├── web/                  # Next.js + TypeScript frontend (canvas based on the React Flow ecosystem)
├── docker/               # docker-compose and env templates
└── sdks/                 # client SDKs

Standalone repos include: plugin-daemon (a Go plugin runtime handling plugin lifecycle and reverse calls), dify-sandbox (code execution isolation), and dify-plugin-sdks.

A few architectural design decisions worth borrowing:

• Task queue decoupling: all heavy work (document indexing, batch annotation, async calls) goes through Celery + Redis, with API processes doing only synchronous orchestration. v1.9's queue-based graph engine deepens the same idea—node execution becomes messages, naturally supporting concurrency and retries.
• Model runtime abstraction: the model_runtime layer flattens dozens of providers' API differences into one unified interface, further pluginized after v1.0. This is the standard solution for "model gateway"-type systems.
• Plugin reverse calls: plugins run in a standalone daemon and can call back into the Dify main program's capabilities (invoke models, read/write knowledge bases), keeping plugins from being islands.
• Security boundaries as separate services: code execution goes through a sandbox container; outbound HTTP goes through an SSRF proxy—these two components get the most questions in enterprise security reviews.

For observability, Dify has built-in logging and annotation, and officially integrates third-party tracing with Langfuse, LangSmith, Arize Phoenix, and others—for production tracing and evaluation, connecting external professional tools directly is advised; the built-in logs are more for debugging.

6. Commercialization Model

Dify is textbook open-core, with three revenue lines:

1. Dify Cloud (SaaS): the free Sandbox tier (200 message credits, 5 apps, 30-day log retention) is the funnel entry; Professional/Team tiers subscribe per workspace annually (annual payment discounted), differing in member count, app count, knowledge base capacity, trigger event quotas, and execution priority. Note that message credits are just a quota for trying out the various models with zero config; once used up you can switch to your own API key—Dify doesn't make money reselling tokens.
2. Enterprise licensing: commercial license + enterprise features (SSO, multi-workspace, audit) + support services, with custom deal sizes. Cloud marketplace listings (AWS/Azure Marketplace) reduce big customers' procurement friction.
3. Ecosystem and partners: a partner network around Knowledge Pipeline and Marketplace (data connectors, document processing, vector optimization vendors); in 2026 the Creator Center and template marketplace launched, letting creators publish templates for monetization—a step toward probing a "platform take-rate" model.

On funding: a $30 million Pre-A round announced in March 2026, led by Sequoia China with GL Ventures (Hillhouse), Alt-Alpha Capital (a Bessemer-incubated fund), 5Y Capital, Mizuho, and NYX Ventures participating, at a ~$180 million post-money valuation. Officially stated use of funds: improving agent reliability, enterprise-grade controls, lowering the building barrier, and building the open-source ecosystem.

7. Comparison with Coze / n8n / LangFlow

Dimension	Dify	Coze	n8n	LangFlow
Origin	Suzhou Yuling (a startup)	ByteDance	Berlin team, automation since 2019	LangChain team
Open source	Modified Apache 2.0	Core open-sourced in 2025 (Coze Studio)	fair-code (Sustainable Use License)	MIT
Core abstraction	LLM apps + agentic workflows	Bots + plugins + skill packs	General automation nodes (400+ SaaS connectors)	A visual shell over LangChain components
Target users	Mixed developer/product teams	Mainly ops/non-technical users	Automation/integration engineers	Developers already on LangChain
Self-hosting	First-class citizen, best experience	Open-source edition deployable but ecosystem bound to cloud	First-class citizen	Self-hostable
RAG	Strong (Knowledge Pipeline)	Adequate	Assemble it yourself	Depends on the LangChain ecosystem
Commercialization	Twin engines of Cloud + Enterprise	ByteDance ecosystem funnel; Coze 3.0 (2026-06) pushes multi-person multi-agent collaboration	Cloud subscription + enterprise edition	Absorbed into LangChain's cloud product line

One-line verdicts:

• Want model neutrality + self-hosting + developer control? Pick Dify.
• Want the fastest output from non-technical staff + ByteDance-channel distribution? Look at Coze.
• When the business is essentially cross-SaaS data moving and automation (LLM as just one link), n8n is smoother; Dify's Triggers are chasing this direction but the connector count is an order of magnitude behind.
• If the team already codes deeply with LangChain/LangGraph, LangFlow is a supplement at most—not worth a stack change.

8. Limitations and Boundaries of Fit

Honestly, Dify's problems are as clear as its strengths:

1. The canvas complexity trap: past a few dozen to a hundred-plus nodes, a Workflow's maintainability falls off a cliff. The canvas has no functions, no modular imports (indirect reuse only via "publish as a tool"), and version management and diff review are far inferior to code. For complex systems, go back to a code framework; for page-level Dify issues see practice pitfalls.
2. The license is not pure Apache 2.0: additional terms restrict reselling Dify as a multi-tenant SaaS—have legal take a look before commercial use; even frontend logo changes are constrained.
3. Enterprise governance is split off: SSO, auditing, and other "serious enterprise must-haves" are locked to the Enterprise edition; the Community edition hits a wall at scale.
4. Performance and stability: the Python + Celery stack needs serious tuning under high concurrency; the community has long complained about occasional execution timeouts and upgrades breaking compatibility (especially during the big plugin-system overhaul). Load test yourself before treating Dify as critical-path infrastructure.
5. The cost of deep customization: once requirements exceed what the canvas and plugins can express, secondary development of the Dify core is not cheap—it's a sizable system, not a toy project.

Scenarios where Dify fits: internal enterprise knowledge-base Q&A/customer-service assistants, AI applications that need non-engineers participating in orchestration, fast PoC to small-and-mid-scale production, and delivering LLM capability as APIs to business systems. Scenarios where it doesn't: consumer high-concurrency products with extreme performance requirements, complex multi-agent research systems, and training/inference-integrated needs requiring deep model behavior customization.

For learners, Dify has one more hidden value: it is an open-book answer to "how to design an agent platform"—pluginization, task queues, model gateways, sandboxes, two-way MCP integration, with readable code for every piece. When you want to build your own, read it first, then start; see Build Your First Agent.

References

• langgenius/dify · GitHub — The official repo, 140K+ stars, with release history and deployment docs.
• The Dify official blog — First-hand source for releases and feature announcements (v1.0 pluginization, v1.6 two-way MCP, v1.13 Human Input, etc.).
• The Dify pricing page — Cloud tier quotas and the Enterprise/Community feature split.
• Dify Closes $30M Pre-A Round (Jiemian News) — March 2026 funding brief, Sequoia-led.
• Docker Compose self-hosting docs — The official quick-start self-hosting guide.
• Dify Marketplace — The plugin marketplace; a direct look at the tools/models/agent-strategy ecosystem.
• Dify 1.9.0: A Brand-New Upgrade for Knowledge Orchestration and the Workflow Engine (Zhihu) — A third-party read of Knowledge Pipeline and the queue-based graph engine.