Open-source RAG platforms compared: which one fits your documents
If your team needs answers grounded in company documents and the stack must run in your own infrastructure, the split is clear: RAGFlow for document-heavy retrieval with deep parsing, Onyx for enterprise search that honors source permissions across many applications, Dify for teams that also want to build visual LLM apps and agents, and AnythingLLM for small teams that want a simpler private document chat. RAGFlow wins when the corpus is messy (scanned PDFs, tables, slide decks) and reviewers need to inspect chunks and citations. Onyx wins when answers must respect who can see each file in SharePoint, Confluence, Slack or Google Drive. Dify wins when the same platform must also serve as your workflow and agent builder. AnythingLLM wins when a small group needs a private assistant without a platform project behind it.
Two license caveats apply up front, and neither makes either product unusable. Dify is released under a modified Apache License 2.0 that requires written authorization to run a multi-tenant environment from its source and bars removing the logo or copyright in the console, so confirm your tenancy model with LangGenius before you build on it. Onyx Community Edition is MIT licensed, but code in its ee directories falls under the Onyx Enterprise License, so confirm which features your rollout needs before you assume they are included. RAGFlow is Apache-2.0 licensed throughout the open-source release, which simplifies the legal review.
Hardware and operating effort differ more than the feature lists suggest. The RAGFlow README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk, and its dependencies include a document engine, MySQL, MinIO, NATS and Kvrocks. The Dify Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM. For Onyx, ask whether you will run Onyx Standard, with background sync workers and model servers, or Onyx Lite, which omits the vector database and workers. Before you commit, run a pilot against your own document set and your real permission model, and confirm connector coverage and sizing in writing.
Matching a RAG platform to your document scenario
This table maps common document scenarios to the platform with the closest supported fit, and names what to confirm before choosing. Read each row as a starting point, since the best fit depends on your sources, identity setup and hardware. The main takeaway is that per-user permission sync and visual agent building point to different platforms, so decide which matters more first.
| Scenario | Best fit | What to confirm |
|---|---|---|
| Scanned contracts and complex PDFs | RAGFlow | Test deep document understanding and chunk visualization on a sample of your own scans, since OCR and table quality vary by document layout. |
| SharePoint, Confluence and Slack with per-user access | Onyx | Confirm the connectors you need, that permission sync covers each source, and whether SSO, SCIM and RBAC require the Enterprise Edition. |
| Visual agent workflows on top of company documents | Dify | Check that the Community edition's single-workspace limit fits, and confirm the modified Apache 2.0 terms if you plan multi-tenant use. |
| Small team with a few hundred documents | AnythingLLM | Confirm the desktop or Docker setup meets your user count and access needs, since this page supplies no sizing facts for AnythingLLM. |
| Air-gapped environment | Onyx | Confirm offline model serving through Ollama, LiteLLM or vLLM, and verify the air-gapped deployment with your own network and update process. |
| Mixed sources with strict audit requirements | Onyx | Verify that query history auditing and usage analytics are in the edition you license, and confirm log retention with your compliance team. |
| Documents plus self-hosted models on limited hardware | No clear fit from supplied facts | Compare the stated minimums (RAGFlow recommends 4 CPU cores, 16 GB RAM and 50 GB disk) against your hardware and test with your document volume. |
How document parsing, connectors and permission sync differ
Every RAG platform runs three stages: parsing and chunking (turning files into text units), indexing (storing those units with embeddings and keyword terms), and answering with citations (retrieving units for a question and pointing back to their sources). The platforms differ most in the first stage and in whether they carry access rules into the third. RAGFlow puts its effort into parsing. Its README describes deep document understanding for complex formats, template-based chunking, and chunk visualization so a reviewer can see and correct how a document was split before answers depend on it. It ingests Word, PowerPoint, Excel, TXT, images, PDFs, scanned copies, structured data and web pages. For a team whose documents are scanned contracts or dense tables, check chunk output on a sample set during evaluation, because bad chunks cause bad citations no matter which model answers.
Onyx takes a different starting point. Its connector model pulls content from more than 50 applications, including SharePoint, OneDrive, Google Drive, Confluence, Jira and Slack, and its README states that it syncs source permissions so answers only draw on documents the user can already see in the source application. If your rule is that a contractor must never see a board paper through a chatbot, this is the behavior to test first: create a restricted document in the source system, confirm it is absent from answers for an unauthorized user, then remove access in the source and confirm the sync reflects it on the schedule you need. Do not assume that a folder-level share in a file store maps cleanly to a chat answer. Dify and AnythingLLM permission behavior against source systems must be confirmed with each vendor before you rely on it. Ask whether they sync source-level permissions at all, how often, and what happens to documents whose access changes after indexing.
Whether permission sync is a hard requirement depends on who will query the index. If every user may see every indexed document, a single shared knowledge base with a clear upload policy may be enough, and parsing quality should decide the platform. If documents carry mixed sensitivity, legal holds or customer-specific access, treat source-permission enforcement as a gating control and make it part of the proof of concept, with a written test plan the security team signs off. Also confirm what the platform does when a connector fails or lags, since a stale permission cache is a data exposure risk rather than a cosmetic bug.
How RAGFlow, Onyx and Dify compare on capability
This table compares RAGFlow, Onyx and Dify on the capabilities that decide retrieval over company documents, including licensing, parsing, permissions, citations and identity. Where the researched facts do not settle a cell, it says what to confirm with the vendor or in a test deployment. AnythingLLM, the option for small teams, is MIT licensed and sits outside these columns.
| Capability | RAGFlow | Onyx | Dify |
|---|---|---|---|
| License | Apache-2.0 | MIT for Community Edition; Onyx Enterprise License for ee code | Modified Apache 2.0; multi-tenant operation needs written authorization |
| Latest release reference | v1.0.0-rc2, published October 16, 2026 (release candidate) | v4.9.2, released October 15, 2026 | 1.17.1, released September 10, 2026 |
| Document parsing and citations | Deep document understanding, template chunking, chunk visualization and traceable citations; ingests PDFs, Office files and scans | Parsing depth not covered by supplied facts; confirm supported formats and OCR path | Parsing and citation behavior not covered by supplied facts; confirm in a pilot |
| Connectors | Web pages, sitemaps and Google BigQuery ingestion, plus file formats | 50+ applications; includes SharePoint, OneDrive, Teams, Google Drive, Confluence, Jira and Slack | Connector catalog not covered by supplied facts; confirm against your sources |
| Permission sync | Not covered by supplied facts; confirm per-document access trimming | Syncs source permissions so answers draw only on documents the user can see | Not covered by supplied facts; confirm before relying on it for restricted content |
| Agents | Agentic retrieval with Low, Medium, High and Ultra thinking modes | Chat, agents and actions in Community Edition | Visual workflows, RAG pipelines and agents, with a prompt IDE |
| Model provider support | Not covered by supplied facts; confirm supported local and cloud models | Ollama, LiteLLM and vLLM, plus Anthropic, OpenAI and Gemini | Many model providers; confirm your specific model and endpoint |
| Index and supporting services | Elasticsearch or Infinity, MySQL, MinIO, NATS and Kvrocks | Postgres, Vespa or OpenSearch, Redis and model servers | PostgreSQL, Redis, Weaviate by default; Qdrant, Milvus, pgvector and others as options |
| SSO and SCIM | Not covered by supplied facts; confirm before deployment | SSO via Google OAuth, OIDC or SAML and SCIM listed as enterprise features; confirm edition | Community Edition is single workspace; SSO via OIDC, SAML and OAuth2 in Enterprise |
| Paid editions | Open source self-hosted; cloud service at cloud.ragflow.io; confirm any enterprise tier | Community Edition, Onyx Cloud and self-hosted Enterprise Edition with RBAC | Community free; Enterprise custom priced; Cloud Professional 590 USD and Team 1,590 USD per year (Dify pricing page) |
What each open-source RAG platform is built for
Each card covers one platform in this comparison. License terms decide deployment as much as features: RAGFlow is Apache-2.0, Onyx keeps enterprise code under its own license, and Dify restricts multi-tenant use and branding. Release references are included so you can check how current each project is.
RAGFlow for document-heavy retrieval
RAGFlow is an Apache-2.0 retrieval engine that combines RAG with agent capabilities. It is built for hard documents: scanned PDFs, spreadsheets, slide decks and web pages, where chunking quality determines answer quality. Chunk visualization lets reviewers inspect what will be retrieved, and citations trace answers back to source passages. Its README recommends 4 CPU cores, 16 GB of RAM and 50 GB of disk, plus a document engine, MySQL, MinIO, NATS and Kvrocks. Latest release: v1.0.0-rc2, published October 16, 2026. Confirm how it handles per-user permissions on ingested sources before rollout.
Onyx for permission-aware enterprise search
Onyx is open core. Its Community Edition is MIT licensed, but code in ee directories falls under the Onyx Enterprise License, and features such as role-based access control sit in that paid tier. It is built for enterprise search across company applications: it connects to more than 50 applications and syncs their permissions, so answers only draw on documents each user can already see. Teams can run Onyx Standard, with full indexing, or Onyx Lite, a lighter chat deployment without a vector database. Latest release: v4.9.2, published October 15, 2026.
Dify for visual LLM application building
Dify is an LLM application platform for building workflows, RAG pipelines and agents through a visual interface, with a prompt IDE and LLMOps monitoring. Its license is a modified Apache 2.0 that requires written authorization to operate a multi-tenant environment from the source and forbids removing the logo or copyright in the console. The self-hosted Community edition is limited to a single workspace, so multi-workspace needs move to the paid Enterprise edition, which is custom priced. The Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM. Latest release: 1.17.1, published September 10, 2026.
AnythingLLM for small document teams
AnythingLLM is an MIT-licensed private document chat and agent application from Mintplex Labs. It runs as a desktop app or as a Docker server, which suits a small team that wants one application for chatting with its own documents without operating a separate retrieval platform. Its scope is narrower than the enterprise platforms in this comparison, so a requirement for many source connectors, per-user permission sync or large-scale indexing points elsewhere. Verify current document types, connectors, permission handling and agent features with the project before you decide.
What hardware and services each platform needs to start
RAGFlow publishes the most specific starting sizing in this group. Treat its README baseline as the minimum for the Docker host, because the document engine and the parsing workload both run on that host.
- Host baseline: The RAGFlow README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk.
- Container runtime: Docker 24.0.0 or later and Docker Compose v2.26.1 or later. macOS is not currently supported for its Docker image.
- Dependent services: A document engine (Elasticsearch or Infinity), MySQL, MinIO, NATS and Kvrocks run alongside the application, so each one needs storage and backup planning.
- Parsing on CPU: In the 1.0 open-source release, DeepDoc runs layout analysis, OCR and table recognition on CPU inference, so scanned or table-heavy document sets raise CPU demand.
Ask InfiniFlow how the baseline changes for your document volume, your choice of document engine and any agentic retrieval modes you plan to enable.
Onyx has two self-hosted shapes with very different footprints, so the first decision is which one fits your use. Onyx Standard runs the full retrieval stack. Onyx Lite is a lighter chat and agents deployment without a vector database or background workers.
- Onyx Standard: Vector and keyword indexing, background sync workers, model inference servers, object storage and Redis, which together support connector-based retrieval with permission sync.
- Onyx Lite: Chat and agents without a vector database or background workers, which reduces the number of services to operate but removes the sync pipeline from the deployment.
- Index and data stores: The documented infrastructure includes Postgres, Vespa or OpenSearch for the index, Redis and model servers.
- Model servers: Self-hosted models run through Ollama, LiteLLM or vLLM, so model choice adds its own hardware requirement on top of the platform footprint.
- Deployment tooling: Docker, Kubernetes, Helm or Terraform, with the Onyx deployment overview as the starting read.
Confirm with Onyx whether Lite can serve your connector-based retrieval, since it has no vector database or sync workers, and request sizing for your connector count and sync schedule.
Dify's Docker Compose deployment is the smallest documented baseline in this group for the platform itself, but it starts many services. The minimum is modest, while the number of containers is what drives operating effort.
- Host baseline: At least 2 CPU cores and 4 GB of RAM, with Docker Compose 2.24.0 or later, according to the Dify Docker Compose guide.
- Application services: The api, worker, web and plugin daemon services, plus other core services.
- Supporting services: PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy.
- Alternative stores: The metadata database can be MySQL or OceanBase, and the vector store can be swapped from the Weaviate default to Qdrant, Milvus, pgvector, OpenSearch or Elasticsearch, which changes what you run and back up.
Confirm with Dify how the 2 core and 4 GB minimum scales with your workflows, document volume and concurrent users, because the documented minimum does not state those limits.
AnythingLLM is the lightest option here for small teams because it runs in two forms: a desktop app for individual use or a Docker server for shared use. The form you pick sets the hardware and services you need, and the facts for this comparison do not give sizing figures for either form.
- Desktop app: Suited to one user on one machine, with no separate server to operate.
- Docker server: Suited to a shared instance that several people reach from the network, which adds host, container and backup duties.
- License: MIT, which keeps the self-hosted deployment simple to adopt, though license is not a sizing factor.
- Model choice: Running a local model needs more memory and compute than calling a hosted provider, so the model decision matters more than the app itself.
- Storage and vector backend: Confirm which default vector store and document storage the release uses, and how they grow with document volume.
Confirm sizing with the Mintplex Labs project documentation and test it with your own document set before you commit to a team-wide Docker server.
Licenses and paid editions decide what you can run and support
The license is the first filter for this shortlist, because it decides whether you can run a platform as a internal service, modify it and sell support around it. RAGFlow is Apache-2.0, which places few restrictions on internal or commercial use of the open-source code. Onyx Community Edition is MIT, but code in ee directories falls under the Onyx Enterprise License, so you need to confirm which directories your deployment and any features you enable touch. Dify is different: its modified Apache 2.0 forbids operating a multi-tenant environment from the source without written authorization (one tenant being one workspace) and forbids removing the logo or copyright in the Dify console. A single-team deployment is unlikely to hit the multi-tenant clause, but a shared internal platform serving several business units or customers may.
Dify's published pricing gives you concrete numbers to plan against. The self-hosted Community edition is free and limited to a single workspace. The self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support, so the fee is set by quote rather than by a list. Dify Cloud Professional is listed at 590 US dollars per year and Team at 1,590 US dollars per year, according to the Dify pricing page. If you need more than one workspace, the cost driver is the Enterprise quote, which should itemize license, support and any implementation work separately.
Have counsel confirm how these licenses apply to your intended use before you commit, especially if the platform will serve partners, subsidiaries or customers. Ask each vendor, in writing, which directories or features fall under commercial terms, and ask DeployOpen to flag any component whose license changes the scope of the engagement. Note that the Community and Enterprise editions differ in support as well as features, so confirm the support window and escalation path you will rely on before you assume the open-source edition meets your operating needs.
How to choose and pilot a RAG platform on your own documents
This sequence takes a team from defining its document sets to a written production scope, with each step producing evidence that the chosen platform parses, cites and permissions content correctly in your environment. It is built so that licensing and hardware questions are settled before anyone commits budget.
Define document sets and access rules
Inventory the document collections you want answered, such as wikis, file shares, ticket exports, scanned contracts and SaaS spaces, and record which groups may see each one today in the source system. Name an owner for each set and note whether permissions live in the source application or in a folder structure. The step is done when every set has an owner, a sensitivity label and a written access rule that a reviewer can check against the source.
Shortlist two platforms against the scenario table
Match your requirements to the scenario table on this page, then keep the two platforms that fit best. RAGFlow is built around deep document understanding and chunk review, Onyx around connectors and synchronized permissions, and Dify around building workflows and agents on top of retrieval. Record why each candidate stays and why the third one drops out. The step is done when the shortlist has a one-line rationale per platform that a non-author can read.
Run a pilot on a representative sample
Assemble a sample that includes clean Word and PDF files, scanned copies, spreadsheets, slide decks and at least one document with complex tables or layout. Deploy each shortlisted platform in a non-production environment in your own infrastructure and ingest the same sample into both. Log parsing failures and time spent per step. The step is done when both pilots have ingested the full sample and the failures are listed by file type.
Measure citation quality with chunk reviewers
Ask two or three reviewers who know the content to write fifteen to twenty questions with known answers, then run them against each pilot. For every answer, have the reviewer open the cited chunk and confirm that it supports the claim, and record whether the chunk boundaries split the answer. Use the chunk visualization features where the platform offers them. The step is done when each platform has a citation accuracy score broken down by file type, reviewed by people other than the builders.
Test permission behavior with a test user
Create a test user in each source system with access to one restricted folder or space and no access to another. Sign in to each pilot as that user, ask questions that touch both areas, and confirm that answers draw only on documents the user can already see in the source. Repeat after removing the user's access in the source to confirm that the platform stops returning those documents. The step is done when the results are written up with screenshots or logs and the permission sync interval is confirmed with the vendor.
Confirm license terms with legal
Ask counsel to review the license of each shortlisted platform and any paid edition you might need, including the features that sit behind enterprise terms, such as SSO, SCIM, multi-workspace support or permission sync. Confirm whether your intended use, including multi-tenant or customer-facing use, is permitted under the license as written. The step is done when legal has signed off on a written summary of permitted use for each platform and the paid features you would require are named.
Size hardware from the README and pilot data
Start from the minimum hardware in each project's README or deployment docs, then scale using your pilot results: corpus size, number of scanned pages, concurrent users and whether layout analysis runs on CPU or GPU. RAGFlow's README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk, and Dify's Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM. Treat these as starting points, not sizing for production. The step is done when you have a written hardware plan that your infrastructure team has reviewed.
Request a written scope before production
Send the pilot results, the access rules, the license summary and the hardware plan to two or three implementation partners, DeployOpen among them if it fits your shortlist, and ask for a fixed-scope proposal covering deployment, connector setup, permission testing, documentation and handover. Ask each to state what is one-time and what recurs, including upgrades and support. The step is done when a written scope, deliverables and timeline are agreed before any production work starts.
Questions buyers ask before choosing or hiring help for a RAG platform
What drives the cost of running RAGFlow, Onyx or Dify?
Cost comes from hardware, model hosting, connector setup, permission testing, licensing and the internal people who own the platform. The RAGFlow README recommends starting with 4 CPU cores, 16 GB of RAM and 50 GB of disk, and Dify's Docker Compose guide asks for at least 2 CPU cores and 4 GiB of RAM for its base stack. Those figures cover the platform only, not a GPU, a model endpoint or the document volume you index. Hardware and cloud spend recur, while integration, testing and documentation are usually one-time. Licensing matters too: Dify's commercial license applies to multi-tenant operation, and Onyx's enterprise features sit in ee directories under a separate license. Ask any vendor or partner for a written quote that lists each of these components separately.
Can our team deploy RAGFlow, Onyx or Dify from the documented Docker steps?
A team with container experience can usually start a single-node evaluation from the documented steps, but a production deployment needs more than the quick start. Dify's Docker Compose path starts the api, worker, web, plugin daemon, PostgreSQL, Redis, Weaviate, Nginx, a code sandbox and an SSRF proxy, and its environment reference covers settings such as SECRET_KEY, which must be set carefully because changing it logs out all users. RAGFlow requires Docker 24.0.0 or later and Docker Compose v2.26.1 or later, and it does not support macOS for its Docker image. Onyx also offers Kubernetes and Helm paths. Your team still needs to own backups, upgrades, TLS, secrets and monitoring. Confirm each of these in your own environment before you commit.
What does the work need from our side before it starts?
Expect to supply a document inventory, identity provider access and source system admin rights, plus named reviewers. An inventory lists which repositories hold documents, their owners, rough volumes and sensitivity, and it decides which connectors you need. Identity access matters because Onyx lists SSO through Google OAuth, OIDC or SAML, SCIM provisioning and role-based access control, and Dify Enterprise documents OpenID Connect, SAML and OAuth2. Source admins must grant read scopes so the platform can sync permissions. Reviewers judge citation quality, since RAGFlow's chunk visualization and traceable citations only help if someone checks them. Ask your implementation partner to list these inputs in the written scope.
How long does a RAG pilot take to run?
No supplied figure gives a reliable duration, so ask for a written estimate built from your scope rather than relying on a number from this page. The main drivers are the number of source systems, how many document formats need parsing and review, whether permission sync must be proven, the model hosting choice and how many people must approve results. A pilot limited to one source and one group of users takes far less time than one that covers several connectors and identity scopes. Ask the provider to state which milestones are fixed, which depend on your access approvals and what happens if an approval is delayed.
Is permission sync required, and how do we verify it?
Permission sync is required for any deployment where users should not see documents their source application hides from them. Onyx states that it syncs source permissions so answers only draw on documents the user can already see, and that is the behavior you should test. Build a test set of users with known access in each source, ask questions whose answers sit in restricted documents, and confirm that no restricted text appears in answers, citations or logs. Repeat the test after a permission change in the source system, since sync timing decides how long stale access lasts. Ask the vendor how sync runs and how often, and confirm the result in your environment.
What happens if the license changes or we run a release candidate in production?
A license change affects what you may do with the code, and a release candidate affects how stable it is. Open WebUI's move from BSD-3-Clause to its own license at v0.6.6 shows how a change can apply from a specific version onward, while code merged before it keeps the older terms. Read the license file for the exact version you deploy and record it. RAGFlow's v1.0.0-rc2 and v1.0.0-rc1 are release candidates, so pin them only for evaluation unless your change plan covers testing and rollback. Ask for a written upgrade policy that states how license terms, breaking changes and security fixes will reach your environment.
Can DeployOpen plan, implement and test a RAG platform for us?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing first. It also runs application and API security testing and can prepare systems and evidence for compliance assessments, although independent auditors issue any attestations. Ongoing support and continuous testing are available as retainers. DeployOpen does not publish a price list, so request a quote based on your written scope. Compare any proposal against the cost components above.
How DeployOpen scopes selection and implementation of a RAG platform
DeployOpen starts with the document sources, permission model and hardware your team already has, then decides which RAG platform fits before any installation begins. The work is delivered as a fixed scope agreed in writing, inside your own cloud accounts, data centers or air-gapped networks.
How we scope
- Inventory the document sources, file formats and permission models that the RAG platform must respect before comparing candidates.
- Confirm which license terms, editions and paid features your organization needs, including multi-tenant or branding restrictions.
- Agree in writing the deliverables, timelines and hardware assumptions for the chosen platform, with any retainer for ongoing support.
How we build
- Deploy the chosen platform and its dependency services inside your infrastructure, following the vendor's documented hardware baseline.
- Configure connectors, chunking, models and access controls, then test citation accuracy and permission enforcement against real user roles.
- Harden secrets, network egress and storage, and document every configuration choice that affects answers or data exposure.
How we hand over
- Deliver runbooks covering upgrades, backups, model changes and connector maintenance so your operators can run the platform.
- Provide evidence of configuration, access controls and test results that your auditors or security reviewers can inspect.
- Walk your engineering and security teams through operations, known limits and the decisions recorded during the engagement.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer when your team wants DeployOpen to keep the platform current.
- Review vendor release notes for each upgrade and test connectors and permissions again before changes reach production.
- Scope any new connector, agent or model integration as a separate written engagement with its own deliverables.
