mrkeyoor.com_
Thu 17 Sept 18:40 UTC
AI Toolsevaluationupdated 25 Aug 2026

ragflow review

RAGFlow is a self-hosted system for turning documents and connected data sources into searchable knowledge bases, cited chat answers, and agent workflows. It bundles parsing, chunk review, retrieval, reranking, model connections, APIs, and a visual interface so a team does not have to assemble each layer separately.

+300stars / 7d
Verdict

RAGFlow is a strong candidate when document parsing and chunk inspection are central to the product, and the team wants a usable interface as well as APIs. It is an application stack, not a drop-in RAG package, so budget for operations, migration tests, provider configuration, and document-specific acceptance tests. Small projects should start with a library or managed service; platform teams can justify RAGFlow when its parsing and review workflow replace several internal tools.

We ran it

Lab card: what happened when we ran ragflowScreenshot of ragflow (ragflow.io)
Install✓ · 590s517 packages · 4302 MB
Build✓ · 11s
Tests✗ · 9sran, no count parsed
Known vulns5(pip-audit)
Repo5730 files~1,340,669 lines of source · 110.2 MB · 4 CI workflows · Dockerfile · tests dir

Answers from our run

Does ragflow build from source?

Dependencies installed in 590 seconds (517 packages), and the build succeeded in 11 seconds. We cloned commit 7cb4e30 into a clean Debian container with 3 CPUs and no project-specific setup.

Do ragflow's tests pass?

The test command failed in our container, and its output did not report a pass or fail count.

Does ragflow have known vulnerabilities in its dependencies?

pip-audit flagged 5 known advisories in the dependency tree at the time of our run.

Who should not use ragflow?

Developers seeking a lightweight library inside an existing app: the documented deployment is a multi-service system with substantial CPU, memory, disk, and operational requirements.

What are the alternatives to ragflow?

Dify, LlamaIndex, Haystack. RAGFlow is a strong candidate when document parsing and chunk inspection are central to the product, and the team wants a usable interface as well as APIs.

Setup2/5Working Compose path, but many services and high host requirements
Docs4/5Clear host, image, source, configuration, and upgrade guides
Community5/5Very active pushes, releases, issue reports, and pull requests
Maturity3/5Broad product with active parser, connector, and migration defects

Discussed on

  1. hnRAGFlow is an open-source RAG engine based on OCR and document parsing230 points
  2. hnDeepSeek-V2 integrated, RAGFlow v0.5.0 is released7 points
  3. hnRAGFlow 0.9 is released to support GraphRAG end-to-end3 points

Who it’s for

Teams building document search or cited assistants across PDFs, office files, images, and business data.
Developers who want a visual way to inspect chunks before trusting retrieval.
Organizations prepared to run databases, object storage, search, model providers, and worker services.
Agent builders who need APIs, workflow components, and MCP support around a shared knowledge base.

Who it’s NOT for

Developers seeking a lightweight library inside an existing app: the documented deployment is a multi-service system with substantial CPU, memory, disk, and operational requirements.
ARM64 operators who need an official ready-made image: the README says current images target x86 and directs ARM64 users to build their own.
Teams expecting the test suite to run without provider secrets: our run stopped during collection because ZHIPU_AI_API_KEY was mandatory.
Owners of irreplaceable connector data who want to enable automatic pruning without safeguards: issue #16636 reports a transient WebDAV listing error being treated as an empty source and deleting synced documents.
Upgrade-sensitive installations that cannot rehearse database migrations: issue #17578 documents model configuration gaps when moving from v0.25.5 to v0.26.4.
Anyone expecting document parsing to be uniformly accurate: current reports cover dropped spreadsheet cells, legacy .doc routing, delimiter behavior, and cross-page tables.

Setup reality

At commit 7cb4e30, installation succeeded in 590 seconds, adding 517 packages and using 4,302 MB. The 5,730-file checkout held roughly 1,340,669 source lines and occupied 110.2 MB. The build succeeded in 11 seconds.

Tests exited 4 after 9 seconds before running cases. Pytest stopped while importing its configuration because ZHIPU_AI_API_KEY was unset. pip-audit found five known vulnerabilities.

The supported self-host path needs at least 4 CPU cores, 16 GB RAM, 50 GB disk, Docker and Compose, plus a kernel setting. You must configure an LLM and embedding provider, passwords, storage, and a document engine. Source development also starts MinIO, Elasticsearch or Infinity, Redis, and MySQL; the code executor requires gVisor.

A full product around retrieval

RAGFlow covers much more than vector search. Users create datasets, ingest files or connected sources, choose a parsing method, inspect the resulting chunks, configure retrieval, and build chat or agent experiences on top. The project handles office documents, PDFs, images, scanned material, structured files, and web content. Answers can show citations back to the retrieved material.

That visual inspection loop is its best reason to exist. Retrieval quality often fails before the language model receives a prompt: a table is split badly, a heading loses its section, or OCR scrambles a page. RAGFlow lets an operator see chunks and adjust the parsing template instead of treating ingestion as an invisible background job. For document-heavy teams, that can be more useful than another abstraction over a vector database.

The system also has agent workflows, APIs, Python and JavaScript clients, data-source synchronization, and MCP support. Those features can put the same curated knowledge base behind several applications. They also make the product large. This is not the right dependency when all you need is a function that embeds ten Markdown files.

Self-hosting means operating a small stack

The README recommends at least four CPU cores, 16 GB of RAM, and 50 GB of disk. Docker 24 or newer and Docker Compose 2.26.1 or newer are required for its main self-host path. Elasticsearch is the default document engine, while Infinity is available as an alternative. The Compose environment also includes MySQL, Redis, MinIO, and RAGFlow services.

Before startup, Linux hosts need vm.max_map_count set to at least 262144. Administrators then choose image and service settings, set database and object-store passwords, and configure an LLM provider plus its API key. The image relies on external language and embedding services. The README warns that official images target x86, so ARM64 users must follow a source-build path.

The code executor adds another security boundary. RAGFlow requires gVisor when that feature is enabled, which is a sensible requirement for running generated code. It still demands careful network policy, resource limits, image updates, and tenant controls. Anyone exposing the service beyond a trusted team should review default accounts and secrets before the first login.

Source contributors take on more. The development guide installs Python dependencies and downloaded assets, starts the backing services, adds local hostnames, installs jemalloc where needed, launches backend workers, then separately installs and runs the web client. The documented steps are useful, but they confirm that this is a distributed application rather than an ordinary Python package.

Parsing is the product and the risk

RAGFlow's parser choices are valuable because documents do not share one reliable shape. General prose, tables, manuals, scanned PDFs, presentations, and spreadsheets need different treatment. Users can review the chunks and adjust delimiters or methods. Retrieval then combines recall and reranking before the selected model writes an answer with references.

Current issues show why acceptance testing must use your real documents. Issue #18459 describes spreadsheet cells being replaced with null when a value does not fit the inferred column type, after which the chunking path omits them. Issue #18621 traces legacy .doc files into a parser meant for .docx. Other active reports cover cross-page table segmentation and custom delimiters producing unexpectedly tiny chunks.

Connector behavior needs the same scrutiny. Issue #16636 reports that a WebDAV listing exception is swallowed and returned as an empty list. With deletion synchronization enabled, that empty result can cause already-synced documents to be pruned. Until that path is fixed and verified, a team using connector pruning should keep backups and test failure behavior, not only successful synchronization.

What happened when we ran it

We cloned commit 7cb4e30 into a fresh unprivileged Python 3.12 Debian container with three CPUs, 8 GB of RAM, and no secrets. The checkout contained 5,730 files and roughly 1,340,669 source lines, occupying 110.2 MB. Installation took 590 seconds, installed 517 packages, and consumed 4,302 MB on disk. The build completed successfully in 11 seconds.

The test command failed with exit code 4 after 9 seconds. Pytest did not reach the test cases. While loading test/testcases/conftest.py, it imported a configuration module that called pytest.exit because ZHIPU_AI_API_KEY was missing. The log proves that this test entry point expects that provider credential; it does not show whether the suite would pass after supplying one.

Our dependency audit found five known vulnerabilities. The repository had four CI workflow files, a Dockerfile, and a tests directory. Installation and build therefore worked in the clean environment, but the default test path was not self-contained. A contributor needs the expected secrets and probably the services represented in the test configuration before treating local validation as complete.

Release pace is high, upgrades need rehearsal

GitHub showed a last push on August 25, 2026, one day after several detailed issue updates. Release v0.27.0 was published August 19. The combined open count was 1,779 issues and pull requests; a separate search returned 1,291 open issues. That is active maintenance around a large user base, plus a sizable support and defect queue.

Fast releases make pinning and migration practice important. Issue #17578 documents three gaps in a migration from v0.25.5 to v0.26.4 that left configured models unusable. Whether or not that exact route matches your install, it is a useful warning: clone production data, run the documented migration against the clone, verify providers and retrieval, then upgrade the live service.

RAGFlow earns its operational cost when staff will use the ingestion UI, chunk inspection, citations, connectors, and shared workflows. If most of that surface would sit unused, LlamaIndex or Haystack gives developers more control with less platform to run. If document behavior is the product, RAGFlow is worth a pilot built around the ugliest files you own.

Alternatives

ProjectWhat it isPick it when
Dify gh↗A visual platform for LLM applications, workflows, knowledge bases, and model providers.pick this instead when application and workflow assembly matters more than detailed document parsing controls.
LlamaIndex gh↗A code-first framework for ingestion, retrieval, agents, and data connectors.pick this instead when you want libraries inside your own service and do not need a complete hosted product.
Haystack gh↗A Python framework for explicit retrieval and generation pipelines.pick this instead when engineers want composable pipeline code and already own the surrounding infrastructure.

What people are saying

  1. [github-trending] infiniflow/ragflow

Sources

  1. RAGFlow README
  2. RAGFlow v0.27.0 release
  3. WebDAV pruning data-loss report
  4. Model migration gaps report
  5. Spreadsheet cell-loss report
  6. Legacy DOC parsing report

More ai tools reviews

rowboat · skills · superpowers-zh · yolov5 · eve · MemOS · the whole board →