Dify or RAGFlow: which fits your document retrieval project
Choose RAGFlow when document understanding is the hard part of your project. If your corpus is full of scanned PDFs, multi-column layouts, tables and slide decks, and every answer must point back to a specific passage, RAGFlow's core features match that problem directly: DeepDoc layout analysis, OCR and table recognition, template-based chunking, chunk visualization for human review and traceable citations. Its README lists these as the reasons it exists, and its ingestion list covers Word, PowerPoint, Excel, PDFs, scanned copies, images and web pages. Choose Dify when retrieval is one part of a broader application. Dify is an LLM application builder with a visual workflow editor, a prompt IDE, LLMOps monitoring, backend-as-a-service APIs and a wide range of model providers. Its RAG pipelines and agents are real, but they are built to serve many app types, not to be the retrieval engine itself.
Before you commit, check three things. First, sample your hardest documents and test chunking and citation quality in each tool, since parsing quality is what decides retrieval quality on scans and tables. Second, decide whether you need one retrieval engine behind several apps or a general platform where many teams build their own apps. Third, check hardware. The RAGFlow README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk, and it depends on a document engine, MySQL, MinIO, NATS and Kvrocks. Dify's Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM, so confirm the sizing you need for your document volume in your own environment rather than relying on either minimum.
Finally, settle the license question early. Dify is released under a modified Apache License 2.0 that forbids operating a multi-tenant environment from its source without written authorization, where one tenant is one workspace, and it also restricts removing the logo or copyright in the console. RAGFlow is Apache-2.0 licensed, so its terms carry fewer restrictions for a service you run for several internal groups or customers. Ask your counsel whether your planned use counts as multi-tenant. In short, the decision turns on document complexity, whether you are building one retrieval engine or many apps, your hardware budget and your multi-tenant license needs.
Which platform fits which document retrieval scenario
This table maps common document retrieval scenarios to the platform that fits each one better and the condition that would reverse the choice. Read each row as a starting point, then confirm the deciding details against your own documents, hardware and team skills.
| Scenario | Better fit and reason | When the other platform wins |
|---|---|---|
| Complex scanned or table-heavy document library | RAGFlow. Its deep document understanding, template-based chunking and chunk visualization were built for PDFs, scans and tables, and the chunks can be reviewed by people before answers rely on them. | Dify fits when the documents are mostly clean text and the main work is the app logic around retrieval, not parsing quality. |
| General internal assistant that also needs workflows and non-RAG apps | Dify. It is an app builder with a visual workflow editor, prompt IDE, agents and backend-as-a-service APIs, so retrieval becomes one node among many. | RAGFlow fits when retrieval quality is the whole product and workflow breadth is secondary to document answers. |
| One knowledge base feeding several apps | Dify, if the apps are built in Dify and the knowledge base is shared across them. Confirm how the knowledge base is exposed to each app in your target version. | RAGFlow fits when the knowledge base should be curated once, with its parsing and citation behavior fixed, and consumed by external applications through its APIs. Confirm the API surface for your use case. |
| Small team on modest hardware | Dify, for the lighter starting point. Its Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM, while the RAGFlow README recommends starting with 4 CPU cores and 16 GB of RAM. | RAGFlow fits when the team can provision the larger host and the document quality gains justify the extra services it runs. |
| Strict citation and traceability requirements | RAGFlow. Its README describes traceable citations and chunk visualization for human review, which suit answers that must point back to exact source passages. | Dify fits when citations are useful but not the core control, and when the team will build its own source attribution in the workflow. |
| Hybrid pipelines mixing retrieval with non-document data | Dify. Its workflows can combine retrieval with API calls, code and branching logic in one visual graph. | RAGFlow fits when the pipeline is document-first and its newer knowledge compilation and website or BigQuery ingestion cover the sources. |
| Licensing and commercial use for a multi-tenant service | Confirm with Dify and your counsel. Dify's license restricts multi-tenant operation from source without written authorization, while RAGFlow is Apache-2.0 licensed. | Dify fits a single-organization deployment with no multi-tenant operation. RAGFlow fits when the Apache-2.0 terms match the service model. |
How Dify and RAGFlow are built and what that means for operations
Both platforms are self-hosted and both run as several containers, but they carry different service stacks and different starting hardware. The cards below cover what each stack contains and what that means for patching, backups and on-call work.
Dify's application service stack
Dify's Docker Compose deployment starts the api, worker, web and plugin daemon services, plus PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy. Each of these is a container you patch and monitor. Before go-live, confirm which metadata database, file store and vector store your team will run, because the environment reference allows alternatives to the defaults and each alternative changes your backup and restore plan.
RAGFlow's dependency stack
RAGFlow depends on a document engine, either Elasticsearch or Infinity, plus MySQL, MinIO, NATS and Kvrocks. Document parsing, chunk storage and file storage each live in a different service, so a restore means restoring several stores to the same point in time. Ask your team which document engine it will operate, since that choice drives most of the tuning and upgrade work.
Hardware starting points
Dify's documented minimum is 2 CPU cores and 4 GB of RAM. RAGFlow's README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk. Dify is cheaper to host for a pilot, but its requirements grow with document volume and model traffic. For RAGFlow, the DeepDoc layout, OCR and table steps run on CPU in the 1.0 open-source release, so plan for CPU headroom during bulk ingestion, not only at steady state.
Docker version requirements
RAGFlow asks for Docker 24.0.0 or later and Docker Compose v2.26.1 or later. Dify's Compose deployment requires Docker Compose 2.24.0 or later. Check your host's Docker and Compose versions against both before you pick a shared build host, and record them in your change log so an OS or runtime upgrade does not break one stack without warning.
macOS is not supported for RAGFlow
The RAGFlow README notes that macOS is not currently supported for its Docker image. Teams that prototype on developer laptops will need a Linux host for RAGFlow, while Dify can be evaluated on a wider range of machines. Plan a Linux test environment early so that ingestion tests run on the same OS and container runtime you will operate in production.
Patching and on-call load
Dify's release cadence has been roughly monthly for minor versions, so expect a steady stream of upgrades to schedule and test. RAGFlow is in a 1.0 release candidate series, so confirm its upgrade path and data migration notes before you commit to a version. In both cases, the on-call burden comes from the number of stateful services, so define which team owns database, search index and object storage incidents before launch.
Capabilities, license and dependencies compared side by side
This table compares licensing, document handling, agents, vector store options, identity features and current release lines for Dify and RAGFlow. Read each row against your own corpus and identity requirements, since a document-heavy retrieval project and a general LLM app project weigh these rows differently.
| Capability | Dify | RAGFlow |
|---|---|---|
| License | Dify Open Source License, a modified Apache License 2.0 that restricts multi-tenant operation and console logo or copyright removal without authorization | Apache-2.0, with no supplied restriction on multi-tenant operation or branding |
| Editions | Community edition is free and limited to a single workspace; Enterprise adds SSO, multiple workspaces and professional support (pricing page) | Open-source release; InfiniFlow also offers a cloud service at cloud.ragflow.io. Confirm any paid self-hosted tier directly |
| Deep document understanding | General document handling inside RAG pipelines; confirm parsing depth against your file types | Deep document understanding for complex formats, with DeepDoc running CPU inference for layout, OCR and tables in the 1.0 open-source release |
| Template chunking and chunk review | Confirm chunking options in your version of the knowledge base settings | Template-based chunking and chunk visualization for human review before answers are built |
| Traceable citations | Confirm citation behavior for your chosen app pattern and model | Traceable citations listed in the README as a way to reduce hallucinations |
| Supported input formats | Confirm supported formats against the current Dify documentation for your version | Word, PowerPoint, Excel, TXT, images, PDFs, scanned copies, structured data and web pages |
| Agents | Visual workflow agents and agent apps inside the Dify workflow builder | Agentic retrieval with Low, Medium, High and Ultra thinking modes, plus knowledge compilation into wikis, graphs and timelines |
| Vector store options | Weaviate by default, with Qdrant, Milvus, pgvector, OpenSearch and Elasticsearch as options | Document engine is Elasticsearch or Infinity, with MySQL, MinIO, NATS and Kvrocks as dependency services |
| Identity features | Enterprise SSO over OpenID Connect, SAML and OAuth2, with Microsoft Entra ID, Okta and GitHub named; Community has no SSO | Confirm SSO and access control options in the current release before planning identity integration |
| Latest release lines | Dify 1.17.1 released September 10, 2026 | RAGFlow v1.0.0-rc2 released October 16, 2026; confirm whether to pin a release candidate or the last stable line |
What the licenses and editions allow for each platform
The Community edition is free to self-host and is limited to a single workspace, which is the first licensing boundary to check. Dify uses the Dify Open Source License, a modified Apache License 2.0 that adds two conditions: it forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization, and it forbids removing or modifying the logo or copyright information in the Dify console.
- Single workspace limit: the free self-hosted edition supports one workspace. Teams that expect separate isolated workspaces on the same install need to plan for that before the build starts.
- Multi-tenant restriction: an illustrative case is one install that serves two business units as separate tenants, or that serves outside customers as tenants. Either setup needs written authorization from LangGenius.
- Console branding: removing or changing the logo or copyright in the console is prohibited, so review any white-label plans against this rule.
- Hosted list prices: according to the Dify pricing page, Dify Cloud Professional is listed at 590 US dollars per year and Team at 1,590 US dollars per year. These are hosted plans, not the self-hosted Community edition.
Ask your legal team to read the LICENSE file against your actual tenancy model, including any future sub-tenant or customer use.
Dify Enterprise is the commercial route for self-hosted deployments that need features the Community edition does not include. According to the Dify pricing page, the self-hosted Enterprise edition is custom priced, so the cost is set by a quote built from a written scope. Ask for the price and the included terms in writing before you compare it with other options.
- Included features: the pricing page lists SSO, multiple workspaces, advanced security, a commercial license and professional support.
- SSO protocols: the Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID, Okta and GitHub. It also has separate SSO scopes for workspace access and web app access.
- Deployment target: the Dify deployment overview says Enterprise can run on Kubernetes for high availability, while Community runs anywhere Docker runs.
- Commercial license: Enterprise includes a commercial license, which is the path for multi-tenant use that the Community terms prohibit. Confirm the exact grant in the contract, including which environments it covers.
- Quote scope: ask how many workspaces are included, which SSO scopes are configured, what support hours apply and who operates the upgrades.
Before signing, confirm in writing that the commercial license matches your tenancy model and that it covers every environment you plan to run.
RAGFlow is licensed under Apache-2.0, a permissive license that allows use, modification and redistribution of the open-source code, subject to its notice and attribution terms. The Apache-2.0 text does not add a workspace-based tenancy limit or a console branding rule. Check the repository's own notices and any InfiniFlow terms before you rely on that reading for a multi-team or customer-facing deployment.
- Permissive terms: the README describes RAGFlow as an open-source RAG engine that combines retrieval with agent capabilities. Confirm the license of the exact tag you deploy.
- Editions: the supplied material does not describe a free tier versus a paid tier for the open-source line, so ask InfiniFlow what, if anything, sits outside the open-source release.
- Release status: v1.0.0-rc1 was published on September 29, 2026 and v1.0.0-rc2 on October 16, 2026, according to the RAGFlow releases page. Release candidates need your own acceptance testing before production use.
- Dependency licenses: the document engine (Elasticsearch or Infinity), MySQL, MinIO, NATS and Kvrocks are separate components, each with its own license to review.
Review the license of every dependency image you pull and record the release tag in your change management records.
InfiniFlow also offers RAGFlow as a cloud service at cloud.ragflow.io, according to the README. Hosted use changes who operates the platform and which service agreement governs your documents, so the open-source license and the cloud terms are separate questions. The supplied material does not give cloud pricing, edition names, service levels or enterprise support terms, so ask InfiniFlow directly.
- Operated service: the cloud offering is a separate operated service from a self-hosted install in your own infrastructure.
- Enterprise options: confirm whether InfiniFlow offers an enterprise license, support tiers or on-premises packages for the open-source line.
- Data location: ask where documents, parsed chunks and embeddings are stored and processed, and which subprocessors are involved.
- Service terms: request written support response terms, the upgrade policy and how release candidates are handled in the hosted service.
If the document corpus is regulated, treat cloud hosting as a separate approval with its own review and do not assume it inherits the self-hosted terms.
What drives the running cost of each platform
Running Dify or RAGFlow costs more in hardware, staff time and upgrade work than in license fees, and the two platforms put that load in different places. The cards below separate the one-time setup from the recurring work, and list what to request in a written quote before you commit.
Hardware starting point
RAGFlow's README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk, and it adds a document engine, MySQL, MinIO, NATS and Kvrocks. In the 1.0 open-source release, DeepDoc runs layout analysis, OCR and table recognition on CPU, so a large parsing backlog consumes compute for hours rather than minutes. Dify's Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM. Ask for a sizing estimate based on your page volume and scanned-document share, not the minimum.
Skills to run each stack
Dify's visual builder lets application teams create prompts, workflows and RAG flows without deep parsing knowledge, so most ongoing work sits with product owners and platform staff. RAGFlow shifts effort toward document pipeline tuning: choosing templates, reviewing chunk visualizations and checking citations on messy source files. Budget for whichever skill set your team lacks, and ask the implementer which tuning tasks are included in fixed scope and which are billed separately.
Upgrade cadence and testing
Dify ships minor releases roughly monthly, with 1.16.0 on July 17, 2026 and 1.17.1 on September 10, 2026, so each upgrade is a recurring test cycle for your workflows and plugins. RAGFlow's 1.0 line was still in release candidates, with v1.0.0-rc2 on October 16, 2026, so a production deployment may face breaking changes before a stable 1.0. Plan regression testing for both, and ask for upgrade work to be priced per release in the quote.
Support and managed options
Dify offers a self-hosted Enterprise edition with SSO, multiple workspaces, advanced security and professional support, priced by custom quote. RAGFlow is also offered as a cloud service at cloud.ragflow.io, which moves hosting and upgrades to the vendor but changes where your documents are processed. Compare what each option includes, including support response terms, and confirm whether the cloud service meets your data residency rules before pricing it against self-hosting.
Edition and license fees
Both projects are free to self-host under their licenses, but Dify's Community edition is limited to a single workspace, and multi-tenant operation or removing console branding needs a commercial license from LangGenius. RAGFlow is Apache-2.0 licensed with no edition gate in its open-source release. Recurring fees come from Dify Enterprise or Dify Cloud subscriptions, while your own cloud compute, storage and staff time recur for both. Ask any vendor to state in writing which fees are one-time, annual and usage-based.
Items to request in a quote
Ask for a written scope that lists hosting sizing for the target document volume, the number of Dify workspaces and users, which upgrades and security patches are covered, and the hours for document pipeline tuning. Request the assumptions behind each figure and the cost of a rerun after a failed parsing batch. Fixed-scope work from DeployOpen is agreed in writing before work starts, and ongoing support, upgrades and testing are available as retainers, so ask for each item separately.
How teams pair Dify with RAGFlow in one stack
One possible pattern gives RAGFlow the ingestion and retrieval layer and gives Dify the application layer. RAGFlow parses the documents, runs deep document understanding and template-based chunking, lets reviewers inspect chunks, and returns retrieval results with traceable citations. Dify then owns the user-facing app, the workflow logic, prompt handling, agent behavior and routing to the model providers. This split only works if the citations survive the handoff, so treat it as a design to prove in a pilot rather than a default.
Before committing, confirm three integration points with the vendors and in your own environment. First, the API access: check which RAGFlow endpoints a Dify workflow can call with a key, and whether Dify's HTTP request or knowledge integration path can pass the chunk text, source document identifiers and citation fields through as structured values. Second, the identity boundary: RAGFlow and Dify each keep their own user, workspace and key model, so decide which system enforces who may query which document set and document how a Dify user's access maps to RAGFlow datasets. Third, secrets and network paths, since each stack has its own service accounts and outbound connections.
Pairing adds operational surface. You run two dependency stacks, RAGFlow with its document engine, MySQL, MinIO, NATS and Kvrocks, and Dify with PostgreSQL, Redis, Weaviate and its sandbox services, and you must patch, back up and monitor both. A single platform is usually the better choice when your documents are simple, your team does not need chunk review, or Dify's own knowledge features already meet the retrieval requirement. Ask DeployOpen or your internal team to write down the upgrade cadence for both products before you accept a two-platform design.
Moving a retrieval project from one platform to the other
This sequence moves a document retrieval project between Dify and RAGFlow without losing the source corpus, the answer behavior or the trust your users place in citations. Each step ends with a check you can record before the next one starts.
Inventory documents and chunking rules
The team that owns the knowledge base lists every source, file type, owner, update frequency and access group, then records how each corpus is currently chunked, including any custom separators, chunk sizes and overlaps. Documents that need deep layout parsing, such as scanned PDFs, tables and slide decks, are flagged separately because they behave differently on each platform. The output is a corpus register that a reviewer signs off before any data moves. Confirm chunk-size and parser settings against the current platform documentation, since the two products expose these controls differently.
Export or re-ingest source documents
Source files are kept in their original form in your own storage, which is the one part of the project that transfers directly. Dify stores uploaded files and metadata in its own database and file storage, so the platform exports should be treated as a convenience copy and the originals checked against your repository. The team re-uploads or re-syncs each source into RAGFlow, then compares file counts, checksums and page counts against the register. The step is complete when every source in the register has a matching record on the target and any gaps are logged with an owner.
Rebuild knowledge bases with templates
Chunking does not move as a file, so the team recreates each knowledge base on RAGFlow using the template that best matches the document type, then reviews chunk visualization on a sample of each corpus. Where Dify used a generic splitter, the chunk boundaries may change, and the reviewer checks tables, headings and figure captions one by one. Embedding and retrieval settings are chosen again on the target and recorded in the register. The output is a set of knowledge bases with a written note of template, parser and retrieval configuration for each one.
Re-create prompts, workflows and agents
Prompt text is copied as plain text into the register, then reassembled in the target's own prompt and agent configuration, because Dify's visual workflow graphs do not carry over to RAGFlow's agent and retrieval setup. Each workflow is written out as a numbered list of inputs, retrieval calls, model choices and output rules so that it can be rebuilt by hand. Model provider credentials are reissued from your secrets store, not copied from the old console. The step is complete when each prompt and workflow has a rebuilt counterpart and a reviewer has checked it against the written specification.
Map access rules and workspace permissions
Access rules are rebuilt rather than migrated, so the team lists which groups may read each knowledge base, which apps are shared and who may edit prompts. The mapping is checked against your identity provider groups, and any Dify SSO or workspace scope that is in use is documented separately, since Dify's SSO features are part of its Enterprise edition. Confirm how RAGFlow handles user and team permissions in your version before assuming parity. The output is a permission matrix that a security reviewer approves, with no knowledge base opened to a broader group than before.
Validate citations and answers on a fixed set
The team writes one fixed set of questions with expected source passages and answers, covering factual lookups, multi-document questions and questions with no answer in the corpus. Both platforms run the same set, and reviewers score each answer for correctness, whether the cited passage supports it and whether the citation links to the right page or chunk. Differences are investigated before cutover, since RAGFlow's traceable citations are a reason to choose it, so weak citations on the target are a blocking issue. The step is complete when the score sheet shows an agreed pass threshold and every failure has a documented fix or accepted exception.
Cut over users and retire the old stack
Users are moved in groups, starting with a pilot group that uses the new knowledge bases alongside the old app for a period agreed in the project plan. The team announces the cutover date, keeps the source platform read-only, and confirms that feedback and bug reports route to the new owner. Once the pilot group has signed off, the remaining users move and the old platform is backed up and decommissioned according to your retention policy. The output is a signed cutover record listing the final corpus counts, the validation scores and the date the old instance was retired.
Where RAGFlow and Dify implementation projects usually run long
The effort in a combined RAGFlow and Dify project sits in four places: preparing the document corpus, designing and evaluating prompts and workflows, sizing hardware and operating dependencies, and proving that answers cite their sources. Plan for each one separately, because a delay in one rarely shows up in the others until testing begins. For RAGFlow, the largest share usually goes to corpus preparation and chunk review. Template-based chunking has to be chosen per document type, and the chunk visualization feature only saves time if someone with domain knowledge actually reviews the chunks for scanned PDFs, tables and mixed-layout files. Ask any partner to estimate this work from a sample of your real documents, not from a clean demo set.
On the Dify side, the work is prompt, workflow and evaluation design. Each knowledge base, retrieval setting, agent tool and workflow branch needs test cases with expected answers, and those cases must be rerun after every model change or platform upgrade. Dify's release cadence is roughly monthly according to its releases page, so a plan should include time to retest after upgrades. Hardware and dependency operations apply to both platforms. The Dify Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM, while the RAGFlow README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk. Confirm the sizing against your document volume and concurrency, and budget for operating the document engine, MySQL, MinIO and Redis or Valkey equivalents that the two stacks bring with them.
Identity and SSO setup and grounded-citation testing close out the schedule. Dify's SSO scopes for workspace access and web app access are separate, and Dify Enterprise is needed for SSO, so confirm the edition and identity provider (such as Microsoft Entra ID or Okta) before design starts. Citation testing means checking that each answer points to the right chunk and page, which requires a reviewed question set and a named reviewer. DeployOpen plans and implements this work inside your own cloud accounts, data centers or air-gapped networks under fixed-scope written agreements, and quotes follow from the agreed scope rather than a published price list. Ask for the corpus, workflow, sizing, SSO and citation-testing tasks as separate line items so you can see which ones drive the total.
Questions buyers ask before choosing Dify or RAGFlow
What drives the cost of running Dify versus RAGFlow?
Both are free to self-host under their open-source licenses, so the recurring cost is infrastructure, staff time and any outside help, not the software. Dify's Community edition is free but limited to a single workspace, while Dify Enterprise is custom priced and adds SSO, multiple workspaces and professional support, according to the Dify pricing page. RAGFlow's cost is driven mostly by the larger host it needs and by its dependency services. Ask any vendor or partner for a written quote that separates one-time setup, recurring hosting and support retainers.
Can our team run Dify or RAGFlow without outside help?
A team with container and database experience can deploy either one from its published guides, but production hardening, upgrades and document pipeline tuning take more effort than a first install. Dify's Docker Compose deployment starts the API, worker, web, PostgreSQL, Redis, Weaviate, Nginx and sandbox services, and RAGFlow depends on a document engine, MySQL, MinIO, NATS and Kvrocks. Dify releases arrive roughly monthly, so someone must own upgrades. Decide which of these you will own in-house before you choose.
What skills and time does each project need?
Plan for DevOps skills for both, plus document processing skills for RAGFlow. RAGFlow's value depends on how documents are parsed, chunked and reviewed, so a team needs someone who can inspect chunk visualizations and tune template-based chunking. Dify work centers on workflow design, prompt iteration, model provider configuration and access control. Ask your implementation partner for a fixed-scope plan that names each skill, who fills it and the acceptance tests for retrieval quality.
Which hardware should we plan for with Dify and RAGFlow?
Plan for more memory for RAGFlow. The Dify Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM, while the RAGFlow README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk. RAGFlow also runs DeepDoc layout analysis, OCR and table recognition on CPU in the 1.0 open-source release, so large scanned archives will load the host heavily. Benchmark your own document set on a staging host before you size production, and confirm storage growth for chunks and original files.
Does Dify's multi-tenant license affect a shared internal platform?
It can. The Dify Open Source License, a modified Apache License 2.0, forbids using the source code to operate a multi-tenant environment, where one tenant is one workspace, without written authorization. It also forbids removing or modifying the logo or copyright in the Dify console. A single department running one internal workspace is a different case from a platform team serving several business units from one installation. Have counsel read the LICENSE file against your planned structure and get written authorization or an Enterprise agreement before rollout.
Can we pair Dify with RAGFlow safely?
Yes, a common pattern is to let RAGFlow handle document parsing, chunking and citations while Dify orchestrates workflows and agents that call it. Both are Apache-2.0 or modified Apache-2.0 projects, so the licensing review is limited to Dify's multi-tenant and branding terms. Keep the two systems on separate hosts or namespaces, restrict network paths to the APIs you use, and test citation traceability end to end. Confirm the integration method and its security controls with your implementation partner before you connect production data.
What security controls should we verify before go-live?
Verify secret handling, outbound request controls and inter-service authentication. Dify's environment reference says SECRET_KEY signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users. Its SSRF proxy blocks internal and private IP ranges, and Dify 1.16.1 added token-based authentication between services and sandbox network isolation. For RAGFlow, confirm access controls on its document engine, MinIO and MySQL services. Ask your security team to test these settings against your own threat model before you accept the design.
How DeployOpen helps you choose, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Dify vs RAGFlow decision, we start from your document types, retrieval requirements and infrastructure limits, then build only the platform or pairing your written scope requires.
How we scope
- Inventory your document formats, volumes and citation requirements before choosing Dify, RAGFlow or both.
- Confirm host sizing against the documented minimums and your expected parsing load, including RAGFlow's 16 GB RAM recommendation.
- Agree in writing which license conditions apply, such as Dify's multi-tenant and console branding limits.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.
How we build
- Deploy Dify and RAGFlow in your environment with their documented dependency services and network controls.
- Configure the vector store, metadata database and file storage choices your security team has approved.
- Test retrieval quality on your own documents, reviewing chunk output and citation traceability before go-live.
- Document the integration path if Dify workflows call RAGFlow knowledge bases, including authentication between services.
How we hand over
- Deliver architecture diagrams, configuration records and runbooks that name every container and dependency.
- Document upgrade steps for both platforms, since each ships releases on its own cadence.
- Walk your platform, security and document-owner teams through admin, backup and restore procedures.
- Provide evidence of configuration and testing that your internal reviewers or external auditors can examine.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover reviewing new Dify and RAGFlow releases before you apply them in production.
- Re-run retrieval and citation tests when you change models, embedding settings or source documents.
- Confirm any Enterprise licensing, SSO or support terms with each vendor directly, since DeployOpen does not resell them.
