RAGFlow and Dify are different products: RAGFlow is a RAG engine built around document parsing, chunking and retrieval, and Dify is an LLM app builder with a knowledge base as one feature. At the pinned versions (RAGFlow v0.27.2 and Dify 1.17.1, both released 10 September 2026), RAGFlow is plain Apache 2.0, while Dify is a modified Apache 2.0 that requires written authorization to run a multi-tenant environment and defines one tenant as one workspace. The Dify community deployment creates one workspace at setup with workspace creation switched off, and Dify's documentation lists multiple workspaces as an Enterprise feature. RAGFlow's default stack is 5 containers, 4 of them datastores whose ports are published to the host; Dify's default stack is 16 containers that publish only the web proxy and a plugin debug port, behind an SSRF proxy that denies private addresses. You can run both: Dify's External Knowledge API calls a Dify-compatible retrieval endpoint that RAGFlow has shipped since v0.13.0, as long as the RAGFlow host is allowlisted in Dify's outbound proxy. This week, put Dify's LICENSE file at 1.17.1 in front of counsel together with your workspace plan.
If you are weighing RAGFlow vs Dify for a self-hosted RAG platform, the two projects look like substitutes: both ingest documents, both answer questions over them, both ship a Docker Compose stack and a chat interface. They are different products. RAGFlow is a RAG engine whose centre of gravity is document parsing, chunking and retrieval. Dify is an LLM application builder: workflows, agents, model plugins and a knowledge base as one feature among several.
For a bank, insurer, hospital group or public body, retrieval quality is not what settles this, and no primary benchmark compares the two products anyway. Three things do. The license: RAGFlow is plain Apache 2.0, while Dify is a modified Apache 2.0 whose multi-tenant condition defines one tenant as one workspace, which matters the moment you plan to give each business unit or legal entity its own space. The stack: what each makes your operations team run, harden and back up inside the perimeter. And whether you need both. Everything below is pinned to RAGFlow v0.27.2 and Dify 1.17.1, both released on 10 September 2026, and comes from the license files, compose files, release notes and documentation at those tags.
The short answer: pick RAGFlow when the hard problem is turning scanned, table-heavy documents into clean chunks and you want a permissive license with no extra conditions. Pick Dify when the hard problem is building workflows and agents on top of retrieval, and have counsel read its license against your workspace plan first. If all you need is a chat front end over a document folder, compare chat portals instead; our Open WebUI vs LibreChat vs AnythingLLM comparison covers that decision.
What RAGFlow and Dify actually are
RAGFlow puts its effort before the vector store. Its DeepDoc module runs layout analysis, OCR and table structure recognition inside the RAGFlow server through ONNX Runtime, so there is no separate parsing service to deploy. For PDFs, v0.27.2 lets you choose DeepDoc (the default), Naive (which skips OCR, table and layout analysis), Docling, TCADPParser, or a vision-language model you configure. Chunking is template driven: 14 modules ship at the tag, covering general text, Q&A, tables, papers, books, laws, manuals, presentations, pictures, whole-document, email, resumes, audio and tags. The v0.27.2 release added self-hosted PaddleOCR-VL deployment, MonkeyOCRv2 parsing and locating Excel citation sources in the document preview. Chats, agents, search apps and memories sit on top, but the reason to choose RAGFlow is what happens to a document before it is embedded.
Dify puts its effort after retrieval. You build apps, visual workflows and agents, and a knowledge base is one of the nodes they can call. Ingestion uses Dify's own extractor by default, with an Unstructured service as an optional container, and a newer RAG Pipeline knowledge base type lets you assemble ingestion steps yourself. Model providers are installed as plugins. Dify can also treat an outside retrieval service as a knowledge base, which is how the two products end up running together.
If parsing quality is the open question, parser choice matters more than platform choice; our Docling vs MinerU vs Marker comparison goes deeper on the parser layer, and the PageIndex vectorless RAG analysis places RAGFlow's parsing-first approach against reasoning-based retrieval.
| RAGFlow v0.27.2 | Dify 1.17.1 | |
|---|---|---|
| Primary job | Parse, chunk and retrieve documents | Build LLM apps, workflows and agents |
| License | Apache 2.0, unmodified | Modified Apache 2.0 (multi-tenant and logo conditions) |
| Default file storage | S3-compatible object store container | Directory on the host filesystem |
| Document parsing | DeepDoc in-process, plus Naive, Docling, TCADPParser or a VLM | Built-in extractor, optional Unstructured, RAG Pipeline |
| Default upload limit | 1 GB per upload request, 32 files per batch | 15 MB per file, 5 files per batch |
| Local model support | Built-in providers: Ollama, vLLM, SGLang, Xinference, GPUStack, any OpenAI-compatible API | Provider plugins from Marketplace, GitHub or a local package file |
| Access model | Team membership plus per-resource sharing scope | One workspace; Owner, Admin, Editor, Normal roles |
RAGFlow and Dify licenses: what regulated buyers settle first
RAGFlow: plain Apache 2.0
The LICENSE file at the RAGFlow v0.27.2 tag is the unmodified Apache License, Version 2.0, and source headers carry the standard Apache notice. If you have seen RAGFlow described as AGPL 3.0, it is not. There is no network copyleft and no additional condition, so one RAGFlow deployment can serve as many internal teams as you like without a separate agreement.
Dify: modified Apache 2.0 with four added clauses
The Dify LICENSE at 1.17.1 opens by calling itself a modified version of Apache 2.0 with additional conditions. It states that Dify may be used commercially, including as a backend service for other applications or as an application development platform for enterprises, and that a commercial license is required when either of two conditions is met: Two more clauses sit under a heading addressed to contributors: Everything else follows Apache 2.0. The file closes with a line stating that the product's interactive design is protected by an appearance patent. Do not read 2a as a right to relicense a copy you already run; that is a legal question for counsel. Read it as a reason to pin the version you reviewed and re-review the LICENSE file at every upgrade.
- 1a, multi-tenant service. Unless Dify authorizes it in writing, you may not use the source code to operate a multi-tenant environment. The license defines a tenant as one workspace, the separated area for a tenant's data and configuration.
- 1b, logo and copyright. You may not remove or modify the logo or copyright information in the Dify console or applications. This restriction does not apply to uses that do not involve the frontend, meaning the web directory in the source or the web image in Docker.
- 2a. The producer can adjust the open-source agreement to be more strict or more relaxed as deemed necessary.
- 2b. Contributed code may be used commercially, including in the producer's cloud business.
One tenant equals one workspace: what that means for business units
The multi-tenant clause is also a product gate. The community deployment creates one workspace at setup and ships with workspace creation switched off, and at 1.17.1 the account service refuses to create further workspaces when that setting is off and also enforces a workspace limit tied to the license. Dify's documentation lists multiple workspaces, for isolation between legal entities, regulatory environments or client projects, as an Enterprise feature, along with custom roles that grant access to specific apps and knowledge bases. Picture a bank that wants retail, wealth and compliance each in their own Dify workspace. It is asking for exactly what clause 1a covers and what the community build switches off. What the text does not settle is whether separate business units of one company count as tenants, or whether running several separate single-workspace deployments avoids the clause. Neither answer is in the license or the documentation. Ask Dify and your counsel; do not design around a guess. If you end up with several isolated deployments or tenants, the isolation problem moves to the vector layer, which our guide to multi-tenant RAG isolation covers.
Questions to put to counsel
- Does each business unit or legal entity that would get its own workspace count as a tenant under clause 1a?
- Do several separate single-workspace deployments, one per unit, fall under 1a?
- If we serve Dify only through its API with our own front end, does 1b fall away entirely for us?
- What does 2a mean for the version we deploy today, and what is our re-review trigger on upgrade?
- What does the appearance patent line restrict if we build our own interface?
What you run on-prem: RAGFlow and Dify stacks at pinned versions
The default RAGFlow stack is 5 containers: the RAGFlow server, Elasticsearch 8.11.3, MySQL 8.0.40, an S3-compatible object store (the service is still named minio but runs the silo image), and Valkey 8. Four of the five are stateful datastores. Elasticsearch can be swapped for OpenSearch 2.19.1, Infinity v0.7.3, OceanBase and others through compose profiles, but choose before you ingest: switching from Elasticsearch to Infinity means taking the stack down with its volumes, which clears existing data.
The default Dify stack is 16 containers, one of them a one-shot permissions job: init, api, worker, worker_beat, web, api_websocket, Redis 6, sandbox, local_sandbox, plugin_daemon, agent_backend, two Squid SSRF proxies, nginx, Postgres 15 and Weaviate 1.39.2. Postgres can be swapped for MySQL 8.0, and the compose file bundles 17 vector-store profiles beyond the default Weaviate, with more available as external services.
Two backup details change the plan. Dify's file storage directory also holds the auto-generated secret key when none is set, so restoring the database without that directory is not a full restore. RAGFlow's documented backup procedure stops every service and archives the Docker volumes, and the page carrying it is community-contributed with a note that it may not be actively maintained. That is a cold, stop-the-world backup; if your recovery objectives need better, plan native backups per datastore.
Neither platform bundles your production embedding model. The RAGFlow image ships no embedding models and offers optional Text Embeddings Inference containers for CPU or GPU; Dify reaches embeddings through a provider plugin. Point both at a self-hosted embedding endpoint you already operate, and see our TEI vs vLLM vs Infinity comparison for choosing the server.
| Component | RAGFlow v0.27.2 default | Dify 1.17.1 default |
|---|---|---|
| Application | ragflow server (web, API, admin, MCP) | api, worker, worker_beat, web, api_websocket, agent_backend |
| Search and vectors | Elasticsearch 8.11.3 | Weaviate 1.39.2 |
| Relational database | MySQL 8.0.40 | Postgres 15 |
| Cache and queue | Valkey 8 | Redis 6 |
| Uploaded files | S3-compatible object store | Host directory under the storage volume |
| Code execution | Not in the default stack | sandbox, local_sandbox |
| Plugins | None in the default stack | plugin_daemon |
| Outbound control | None bundled | Two Squid SSRF proxies |
| Web entry point | Served by the ragflow container on 80 and 443 | nginx |
| Containers | 5 | 16 (one one-shot) |
| Data to back up | 4 volumes: Elasticsearch, MySQL, object store, Valkey | Postgres, Redis, Weaviate, file storage, plugin and sandbox directories |
Running RAGFlow and Dify air-gapped: egress and upgrades
What has to change for an offline install
Dify's 1.17.1 defaults assume internet access. An update check calls Dify's update server, the plugin marketplace is enabled, plugin signature verification is on, the code sandbox has network access, and Weaviate telemetry is not disabled. The outbound proxy allowlists the marketplace domain. Each of these is a setting to review before the first boot. Model providers are plugins, installed from the Marketplace, from a GitHub repository, or from a local package file for private integrations, so an air-gapped install brings provider plugins in as local package files and keeps the signature setting deliberate rather than defaulted. Four images in Dify's default stack are pinned to latest: both Squid proxies, nginx and the busybox init job. Several optional profiles are on latest as well, including OpenSearch, Oracle, seekdb and Unstructured. Latest tags break change control twice over: a mirror refresh silently changes what you run, and an auditor cannot tell which build was in production. Resolve each to a digest, mirror it internally and pin the digest. RAGFlow's offline work is narrower: mirror its images, pin them, and point its model providers at internal endpoints. One default to fix early: the container timezone ships as Asia/Shanghai, which puts audit-relevant timestamps in the wrong zone for any deployment that does not run on China Standard Time. Both platforms talk to local vLLM, Ollama or any OpenAI-compatible endpoint; our air-gapped vLLM deployment guide covers keeping that model server from calling out.
Upgrades are where data gets hurt
Dify 1.17.1 is a concrete example. Its release notes tell self-hosted users of the bundled Weaviate to perform a manual, staged upgrade before starting 1.17.1, because Weaviate jumps from 1.27.0 to 1.39.2, twelve minor versions, and skipping minors is unsupported. The notes warn that pulling and restarting can silently and permanently break vector search. The same release fixed knowledge-base extraction bugs, such as CSV codes with leading zeros turning into floats, and told users to re-import affected documents because indexed text is not repaired retroactively. Budget re-ingestion into your upgrade plan. RAGFlow's next step is larger. v1.0.0-rc1 (29 September 2026) and v1.0.0-rc2 (16 October 2026) are release candidates of a rewrite in Go that moves the message queue from Redis to NATS and adds Kvrocks for cache and checkpoints. On startup it migrates v0.27.2 data, and the rc1 notes state the upgrade is irreversible: once completed, data cannot be rolled back to v0.27.2. You must already be on v0.27.2 and back up first. rc1 dropped the Team and Me sharing model and the local sandbox, and ran DeepDoc on CPU only; rc2 restored team sharing and added arm64 images. Stay on 0.27.x in production until 1.0 is generally available.
RAGFlow and Dify security defaults
The two defaults point in opposite directions. RAGFlow's compose publishes its datastores to the host: Elasticsearch, MySQL, the object store's API and console, and Valkey all get host ports, alongside the web interface on 80 and 443, the API on 9380, admin on 9381, MCP on 9382, and 9383 and 9384 for the Go servers. On a flat internal network that puts four datastores one hop from every workstation. Dify's default stack publishes only nginx on 80 and 443 and the plugin daemon's debugging port, 5003; Postgres, Redis and Weaviate stay on the internal Docker network.
For RAGFlow, unpublish or firewall every datastore port before the first document goes in; our self-hosted vector database hardening guide covers the datastore side. For Dify, close the plugin debugging port in production.
Dify's SSRF proxy is a real control. Outbound HTTP made by Dify's API and workers, such as workflow HTTP requests and External Knowledge calls, goes through Squid, as does the code sandbox's traffic. Squid denies private ranges (10/8, 172.16/12, 192.168/16, loopback, carrier-grade NAT, link-local and IPv6 unique local) before it consults any allowed domain. An internal service on a private address is blocked until it is explicitly allowlisted. That is the right default for a regulated network, and it means every internal endpoint Dify must call is a change request.
Dify's example environment files ship fixed, publicly known passwords and keys (database, Redis, sandbox, plugin daemon, agent server, Weaviate), and its compose file falls back to the same database and Redis defaults when a value is unset, so every untouched install starts with the same credentials. RAGFlow's Docker documentation likewise lists a default password for its optional Kibana. Rotate all of them before first boot, not after.
Access scoping differs. Dify 1.17.1 added knowledge-base API keys bound to specific knowledge bases; before that, one key could read and write every knowledge base in the workspace, and keys created earlier stay workspace-wide after the upgrade, so reissue them. RAGFlow layers team membership, a sharing scope per resource (knowledge bases, agents, chats, search apps and memories can be shared to the team) and operation permissions.
Dify and RAGFlow together: Dify workflows over RAGFlow retrieval
The pattern that answers "Dify and RAGFlow" rather than "or" is documented on both sides. Dify's External Knowledge API sends each retrieval request to the external service's retrieval endpoint with a Bearer key, passing the query, the knowledge base ID, top-k, a score threshold and optional metadata conditions, and expects a list of records back. RAGFlow added support for Dify's knowledge base API in v0.13.0, released in October 2024, and at v0.27.2 serves a Dify-compatible retrieval endpoint that requires a RAGFlow API key, refuses knowledge bases outside the caller's tenant, supports metadata filtering, and returns content, score, title and metadata.
Documents, parsing, chunking and the index stay in RAGFlow. Dify gets read-only retrieval and cannot modify or manage RAGFlow content, which keeps document custody in one place. Once a Dify knowledge base is created, its External Knowledge API binding and External Knowledge ID cannot be changed, so map each Dify knowledge base to its RAGFlow knowledge base deliberately before you build apps on it.
The on-prem gotcha is the SSRF proxy. Dify sends External Knowledge calls through it, and because the private-network deny comes before the allowed-domains rule at 1.17.1, adding the RAGFlow domain to the allowed list is not enough when it resolves to a private address. The RAGFlow host has to go on Dify's private allowlist.
The cost is two stacks: 21 containers in the default configurations, two sets of datastores to back up, two release trains and two credential sets. Take it when you need RAGFlow's parsing and Dify's workflows together, not as a default.
RAGFlow vs Dify decision matrix by scenario
The second row deserves the most attention. If your plan for Dify already contains the word "workspace" next to the name of more than one business unit, you are in Enterprise territory or a counsel conversation before you are in an architecture one.
| Scenario | Pick | Why | License check | Ops cost |
|---|---|---|---|---|
| One internal assistant team, one workspace | Either; Dify if workflows matter | Single workspace fits the community build | Dify: confirm 1a with counsel | Dify 16 containers, RAGFlow 5 |
| Several business units needing hard isolation | RAGFlow, or Dify Enterprise | Multiple Dify workspaces are an Enterprise feature | Dify: 1a is the central question | Per-unit deployments multiply backups |
| Scanned or table-heavy documents | RAGFlow | DeepDoc OCR and table recognition, 14 templates, 1 GB upload limit | None beyond Apache 2.0 | 4 datastores with published ports to lock down |
| Workflow- and agent-heavy apps | Dify | Workflows, agents and plugins are the product | 1a, plus 1b if you ship its frontend | Egress, latest-tag pinning, plugin packaging |
| API-only backend with your own front end | Dify or RAGFlow | Both expose retrieval APIs | Dify: 1b does not apply without the frontend; 1a still does | Same stacks as the rows above |
| Hard documents and complex workflows | Both | Dify orchestrates, RAGFlow parses and retrieves | Both licenses, reviewed together | 21 containers, SSRF allowlist entry |
Choosing RAGFlow or Dify: what to do this week
Two things, both small. First, put the Dify LICENSE file at tag 1.17.1 in front of counsel with a one-page description of how many workspaces you intend to run and for whom, plus the questions above. That answer decides whether Dify is on the list at all.
Second, for whichever stack survives, list every container, published port and data directory it creates, and mark each with an owner, a backup method and a pinned digest before the first document goes in. If RAGFlow is on the list, stay on 0.27.x until 1.0 is generally available and rehearse the irreversible migration on a restored copy.
This is the work we do at Particula Tech on client infrastructure: the license review alongside your counsel, the pinned and mirrored stack, and the retrieval layer behind it. For the wider design space around self-hosted retrieval, start from our RAG systems guide.
FAQ
Quick answers to the questions this post tends to raise.
