RAGFlow

Last reviewed Aug 26, 2026 · 807 words

The parser is the product. Most self-hosted RAG tools bolt a vector search onto a naive text extractor, then wonder why answers sourced from a scanned invoice or a 40-page spec with tables come out garbled. RAGFlow (Apache-2.0, 89,000 GitHub stars despite only appearing in 2024) inverted the priority: its "deep document understanding" layer reads layout — tables, multi-column pages, scans needing OCR — chunks with that structure intact, and returns answers with citations that point at the exact passage. If your documents are clean markdown, this is overkill. If they are the PDFs real organizations actually produce, it is the difference between a demo and a tool.

Chunking you can see is chunking you can fix

RAGFlow's most underrated feature is visual chunking: after ingestion you can open any document and inspect exactly how it was split, with the parsed tables and sections laid out, and intervene where the parser guessed wrong. Every RAG pipeline lives or dies on chunk quality, and most tools make it invisible — you discover bad chunking only through bad answers. Being able to audit it per-document, choose different chunking templates per knowledge base (papers, manuals, legal, Q&A), and re-parse selectively is what makes RAGFlow feel like an engine rather than a black box. The citation-grounded answers follow from this: because chunks retain their position in the source, the citations are precise enough to verify, which is the entire point of running retrieval instead of fine-tuning.

The bill: 8 GB of RAM and one kernel setting

The catalogue's 8,192 MB minimum is honest, and it goes to a genuine multi-container stack: the RAGFlow server and task workers, plus a search engine (Elasticsearch by default), object storage, a cache, and a database. Two consequences before your first docker compose up. First, Elasticsearch refuses to start unless the host allows enough memory-mapped areas — set vm.max_map_count to at least 262144 (sysctl -w vm.max_map_count=262144, then persist it in /etc/sysctl.conf); this single line is the most common first-run failure. Second, do not put this on the same 8 GB box already running your media server. RAGFlow wants its own VM or a machine with 16 GB total, and document parsing is CPU-hungry in bursts — ingestion of a large batch will pin cores for a while. Once up, the web UI answers on the ports the compose file maps (80/443 by default; edit the mapping if the box already has a web server).

It brings the pipeline, you bring the models

RAGFlow ships the machinery — parsing, chunking, retrieval, reranking, knowledge base management, a multi-user web app, and an API — but the LLM and embedding models are yours to supply. Provider support is broad: OpenAI, Anthropic, Gemini, DeepSeek and the rest of the API crowd, or fully local generation through Ollama for a pipeline where documents never leave your network. That last configuration is the honest self-hosted story: a private, on-premises answer to NotebookLM that reads your contracts and internal docs without a cloud upload. Note that image variants differ in whether embedding models are bundled — the slimmer image expects you to point at external embedding services, the larger one is a bigger download that works offline out of the box; check the tag you pull.

Against AnythingLLM, it wins on documents and loses on ease

The obvious rival is AnythingLLM, which installs in minutes, runs in a fraction of the memory, and suits a single person chatting with a folder of files. RAGFlow beats it exactly where its parser and chunking controls matter — dense PDFs, tables, scans, multi-user knowledge bases with per-base configuration — and loses on footprint and time-to-first-answer. My full breakdown is in AnythingLLM vs RAGFlow, but the deciding question is simple: if you would describe your corpus as "documents" rather than "files," RAGFlow is worth the extra weight. Teams also get proper multi-user support here, which most lightweight RAG UIs still fake or skip.

What I'd do

Pull the compose stack onto a dedicated VM with 16 GB of RAM, set vm.max_map_count before first boot, and run a two-hour trial with the 20 ugliest PDFs you have — scans, tables, the works — because the parser is the reason you are here and your own documents are the only benchmark that counts. Wire generation to an API model for quality during the trial, then decide whether Ollama-only mode is worth it for privacy. If the trial documents are mostly plain text and you are the only user, stop, install AnythingLLM instead, and give the 8 GB back. Mine are not, and RAGFlow is the one that stayed on my server.