Ragflow-Plus for RAG administration and document analysis

Ragflow-Plus management scope

Ragflow-Plus addresses a specific operational gap in Ragflow: the need to administer users, teams, files, configuration, and knowledge bases through an additional back-end management system while reducing the permissions exposed in the front-end interface. The intended users are therefore not only developers building a retrieval-augmented generation application, but also administrators responsible for a shared installation. The repository description calls it a second-development version intended to be more concise and practical, and the README positions it as a Chinese application-focused solution.

The management layer is a meaningful distinction from using Ragflow directly. Its documented capabilities cover user management, team management, configuration management, file management, and knowledge-base management. At the same time, the front-end permissions are deliberately narrowed. That can make a shared deployment easier to control, although the README does not provide a permission matrix or a detailed description of every administrative action. An engineer evaluating the project should inspect the `management/` directory and its documentation before assuming that a particular role model is available.

Ragflow-Plus also changes document behavior. It uses MinerU instead of the DeepDoc algorithm and supports image parsing. The answer presentation layer can include images associated with cited text blocks, while a document-writing mode changes how users interact with the application. These features target document-heavy workflows, but the repository does not quantify parsing accuracy, image coverage, or the cost of running MinerU in a particular deployment.

Ragflow-Plus parsing and answer data flow

The visible repository layout shows that this is a full-stack platform rather than a single parser package. The `api/` directory contains the application service layer, `rag/` contains retrieval-augmented generation code, `graphrag/` and `agentic_reasoning/` hold related reasoning components, and `web/` contains the front-end. A `management/` directory backs the administrative features described in the README. This arrangement indicates that document ingestion, retrieval, model interaction, answer rendering, and administration are separate concerns within one deployable project.

The documented parsing path uses MinerU for file analysis and adds image parsing. In an answer, the system can return referenced text blocks together with images associated with those blocks. The README does not expose the intermediate schema for citations, image references, or retrieval results, so the exact data flow cannot be reconstructed from the available repository files. That missing detail matters when integrating the platform with another interface. A consumer needs to know whether image metadata is returned inline, through a separate endpoint, or only after the cited block has been stored.

The project also supports a document-writing mode. The README describes this as a new interaction experience, but does not specify its prompts, persistence model, editing controls, or export behavior. It would be premature to treat it as a general collaborative editor. Based on the repository layout, the safe conclusion is narrower: Ragflow-Plus extends the existing RAG application with administrative and document-oriented behavior, while the available documentation leaves the detailed contracts unspecified.

Docker startup for Ragflow-Plus

The README provides one supported quick-start route for Docker. Before the first startup or an upgrade, configure a unique random `MANAGEMENT_JWT_SECRET` of at least 32 bytes and a non-default `MANAGEMENT_ADMIN_PASSWORD` of at least 12 characters. The README links these requirements to `docs/security/jwt-secret.md`; the contents of that file are not available here, so the exact configuration file syntax is not documented in the README.

The documented startup command is:

docker compose -f docker/docker-compose.yml up -d

This starts the Compose-defined services in the background. The repository includes `docker/`, a `Dockerfile`, and Docker-related configuration, so this is the appropriate first installation path for an operator who wants the complete application. The README does not give a local Python installation procedure, a frontend-only startup command, a health-check URL, or a first-login workflow. After the services start, the documented project documentation and video tutorial are the places to follow for account access, initial configuration, and creation of the first knowledge base.

The Dockerfile also shows a concrete build base and dependency step. It starts from `infiniflow/ragflow:v0.17.2-slim`, copies the application directories, installs `transformers==4.49.0`, `torch==2.7.0`, and `torchvision==0.22.0`, then builds the `web/` application with npm. This means a Docker deployment is not merely a thin wrapper around the Python package. It includes a substantial dependency installation and a front-end build, which should be considered when planning build time, image size, and host requirements.

Ragflow-Plus permissions and deployment boundaries

The front-end permission reduction is useful when an installation has more than one user group, but the README does not explain whether permissions are enforced in the API, the interface, or both. That distinction affects adoption. A hidden button is not the same as a server-side authorization check. The repository identifies a `management/` directory, yet it does not provide a complete role and capability reference in the README, so access-control behavior should be verified directly in the deployment documentation and relevant source files.

The deployment also inherits the operational surface of RAG systems. The project metadata lists integrations and dependencies for cloud storage, search, document processing, language models, databases, and web crawling. The dependency file includes packages such as `elasticsearch`, `minio`, `psycopg2-binary`, `valkey`, `openai`, `anthropic`, `cohere`, `groq`, and `ollama`. These names indicate supported or inherited integration points, but the README does not say which services are required for a minimal local run or which are optional. Compose configuration and environment files therefore need to be read before estimating infrastructure.

There is a version distinction worth noting. The README displays version 0.5.0, while `pyproject.toml` identifies the project as `ragflow` version `0.18.0`, and the Dockerfile is based on `infiniflow/ragflow:v0.17.2-slim`. The repository contains multiple upstream-derived versions or metadata layers, so operators should not infer a single runtime version from the README badge alone. Upgrading without checking the compose file and release notes can also affect authentication secrets, stored data, and the balance between the management layer and upstream RAG services.

Ragflow-Plus versus direct Ragflow and MinerU

The direct alternative is upstream Ragflow. Direct Ragflow is the underlying RAG engine, while Ragflow-Plus adds a management console, reduced front-end permissions, MinerU-based parsing, image-related answer output, and document-writing behavior. An organization that already has its own administration layer and does not need those changes may find the additional fork unnecessary. An organization that needs centralized user, team, file, configuration, and knowledge-base administration may prefer the added layer despite taking on a second-development project.

MinerU is another related but different choice. The README names MinerU as the replacement for DeepDoc in this fork. Choosing MinerU directly as a standalone document parser is appropriate when the requirement is parsing rather than a complete RAG application. Choosing Ragflow-Plus adds the application workflow around parsing: retrieval, cited answers, image-associated blocks, user-facing controls, and management features. The README does not provide a benchmark or a formal comparison with DeepDoc, so the claim that parsing is better should be treated as a project design choice, not a measured guarantee.

Ragflow-Plus maintenance and license cost

The repository is not archived, and its last push was on 2026-10-04. The listed releases are `v0.5.0` from 2025-08-10, `v0.4.3` from 2025-06-13, and `v0.4.2` from 2025-06-10. This shows that the repository has recent repository activity, but the available release list does not establish how frequently production deployments receive fixes or whether every upstream change is incorporated.

Ragflow-Plus uses AGPL-3.0. The README states that derivative or modified works must remain under AGPL-3.0 and that users of a network service must be able to obtain the corresponding source code. It also says commercial use is allowed, including SaaS and internal deployment, while closed-source commercial use requires written authorization from all relevant copyright holders. These statements describe the project's license notice, not legal advice. Organizations planning a hosted service or a proprietary modification should review the actual `LICENSE` file and obtain appropriate legal review before deployment.

The upgrade cost is not limited to replacing a container image. The management authentication secret and admin password must be handled as deployment configuration, the relationship between `v0.5.0`, `pyproject.toml`, and the base image needs checking, and persistent data compatibility is not documented in the README. The `management/` and Docker configuration should be reviewed before applying a release, especially when an installation contains uploaded files, knowledge bases, users, or citations.

What to verify before adopting Ragflow-Plus

The first verification point is deployment identity. The README presents Ragflow-Plus as version 0.5.0, but project metadata and Dockerfile contain other version references. Confirm which application version the Compose file starts, then inspect the required environment configuration before the first launch. The README explicitly requires unique, sufficiently long management credentials, making this a release-blocking check rather than optional hardening.

Second, verify the actual management behavior. The documented feature list is broad, but it does not define roles, authorization boundaries, audit logging, user provisioning, or recovery procedures. Confirm that server-side access controls match the front-end restrictions, especially for file and knowledge-base administration. Third, verify parser and image behavior with the document types and languages used by the organization. The README says MinerU replaces DeepDoc and that image parsing is supported, but it gives no accuracy figures or compatibility matrix.

Finally, check model and service dependencies before choosing a production topology. The dependency list includes multiple model providers and storage or data services, while the README does not identify the minimum Compose profile. Confirm resource requirements, network access, persistent volumes, backups, and upgrade instructions in the project documentation. Those checks are more informative than relying on the fork's Chinese-focused feature summary alone.

Editorial conclusion

Adopt Ragflow-Plus when your deployment needs an administrative layer, controlled front-end permissions, MinerU document parsing, and citations that include related images. Do not treat it as a drop-in lightweight RAG library or assume its AGPL-3.0 licensing is compatible with a closed-source service. Verify the Docker configuration, MANAGEMENT_JWT_SECRET and MANAGEMENT_ADMIN_PASSWORD requirements, backing services, model integrations, and the exact upgrade path before deploying it in production.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. zstar1003/ragflow-plus on GitHub