FastGPT: a self-hosted RAG and workflow platform for teams that want the whole stack in one place

The problem FastGPT addresses: RAG is four problems wearing one name

Building a question-answering system over private documents usually means stitching together a file parser, a chunking strategy, a vector store, a retrieval and reranking layer, a prompt orchestrator, and an HTTP API. Each piece has its own configuration surface and its own failure modes. FastGPT's README describes it as an "AI Agent 构建平台" that ships data processing and model invocation out of the box, with Flow-based visual orchestration for complex scenarios. In practice that means the project takes a position on all four layers rather than one.

The intended user is a team that has documents and wants answers, not a team that wants to write retrieval code. The README's feature table is the clearest statement of scope: application orchestration with Agent Skill nodes and conversation or plugin workflows, knowledge base features including multi-library reuse, chunk-level edit and delete, and hybrid retrieval with reranking, plus an operations layer with login-free share pages and iframe embedding. That is a product, not a library.

The trade-off is visible in the same table. Several entries are unchecked: assisted workflow generation, an advanced orchestration debug mode, application node logs, RAG module hot updates, Agent-loop hot updates, and AI-generated plugins. Anyone evaluating FastGPT should read the unchecked rows as the current boundary, because they describe what you will still have to build or work around.

How FastGPT is put together: ingestion, hybrid retrieval, Flow orchestration, OpenAPI

The repository layout confirms a monorepo built with pnpm workspaces and Turborepo. The package.json defines workspace-scoped test targets for @fastgpt/app, @fastgpt/admin, @fastgpt/global, @fastgpt/service and @fastgpt/web, which tells you the system is split into a Next.js front end, a service layer, and shared global types. A separate sdk/ directory and a build:sdks step in postinstall indicate client SDKs are generated from the same source of truth.

The data path, as the README describes it, runs from document import through chunking to retrieval. Import supports manual entry, direct segmentation and QA-style splitting, with file loaders for TXT, MD, HTML, PDF, Docx, PPTX, CSV and XLSX, plus URL reading and CSV batch import. Retrieval is hybrid with reranking, and chunks remain individually editable and deletable after import, which matters when a bad chunk silently poisons every answer that cites it.

The orchestration layer is Flow-based. The README lists conversation workflows, plugin workflows, user interaction nodes and basic RPA nodes, and marks bidirectional MCP support as done. Bidirectional is the interesting word: it implies FastGPT can both consume MCP tools and expose itself as one. The README does not spell out the transport or the configuration keys, so treat that as something to confirm against the documentation before designing around it.

On the API side, the README links an OpenAPI document at cloud.fastgpt.io/apidoc/systemopenapi. That is the integration surface for anything that is not the bundled web UI.

Installing FastGPT with Docker and running a first knowledge base query

The README gives a two-step Docker path. The first command downloads a configuration file and walks you through the inputs; the second starts the stack. Run them from a directory where you are willing to keep the generated Compose file and its volumes.

bash <(curl -fsSL https://doc.fastgpt.io/deploy/install.sh)
docker compose up -d

After the stack is fully up, the README says FastGPT is reachable at http://localhost:3000 with the default account root and password 1234. Change that password before the port is reachable from anything but your own machine, because the default is published in the README and every scanner knows it.

Once you are logged in, the first real use is a knowledge base rather than a chat. Create a knowledge base, import a document, and let the default segmentation run. The README states that chunks can be modified and deleted after import, so open the chunk list and check a few boundaries before you build anything on top.

Then create an application, attach the knowledge base, and use the single-point search test that the README lists under application debugging. That test lets you query the knowledge base directly without going through a model, which separates retrieval quality from generation quality. If the right chunk does not surface there, no amount of prompt tuning in the workflow will fix it.

For anything programmatic, the OpenAPI document linked from the README is the entry point. The README does not publish a base URL, authentication scheme or endpoint list, so read the API doc rather than guessing at paths.

Where FastGPT is the wrong tool

The clearest limitation is the one the README states itself. Several capabilities that a production deployment would want are unchecked, including application node logs and an advanced orchestration debug mode. Full call-chain logging is listed as done, so you get request-level traces, but the README does not document node-level logging for a workflow. If your debugging model assumes you can inspect the input and output of each node in a failed run, verify that before committing.

Licensing is the second constraint. The repository's license is reported as NOASSERTION, which means the licence could not be classified automatically. The repository does contain a LICENSE file, but its terms are not summarized in the README. For a self-hosted internal tool that may not matter. For anything you redistribute or embed in a commercial product it is the first thing to read, and this is a factual gap rather than a legal opinion.

Licence aside, FastGPT is a poor fit when you only need retrieval. If your application already has its own API and orchestration, pulling in a Next.js monorepo, a service layer and a Compose stack to get hybrid search is a large amount of surface area for one capability. A retrieval-focused library would be the smaller dependency.

The commercial split is worth naming too. The README points to a commercial version for more complete functionality and deeper support, and to a cloud service for teams that do not want to self-host. The community self-hosted edition is the one described in the quick-start, and it is the one the unchecked feature list applies to.

FastGPT compared with Dify and RAGFlow

The comparison people actually search for is FastGPT against Dify, and the second is against RAGFlow. The difference is where each puts its weight.

FastGPT's README leads with "开箱即用的数据处理、模型调用" and Flow-based orchestration, and its feature table gives equal billing to knowledge base mechanics (multi-library reuse, chunk edit and delete, hybrid retrieval with reranking, API knowledge bases) and to application concerns (share pages, iframe embedding, conversation logs, annotation). The project treats retrieval quality and application delivery as one product.

RAGFlow is a retrieval-focused system. If your main problem is parsing awkward documents and getting chunks right, a tool built around that problem will go deeper on document understanding than a platform that also ships a workflow editor and a chat front end. FastGPT's answer to the same problem is its loader list and its manual, direct and QA segmentation modes, which is a narrower set of knobs.

Dify is the closer architectural sibling: both are self-hostable platforms with visual orchestration and a knowledge base. The distinguishing details in FastGPT's README are bidirectional MCP support, plugin workflows with RPA nodes, and an explicit OpenAPI document. If MCP interop is central to your design, that is the feature to compare first, and the README does not document the MCP configuration, so the comparison has to be made against each project's own docs.

A fourth name in the same search space is AnythingLLM, which the related searches surface alongside these. The README says nothing about it, so no comparison is offered.

Maintenance cadence, upgrade cost and the licence question

The last push to the repository was on 2026-09-09, and the most recent release listed is v4.16.2 on 2026-09-03, preceded by v4.16.1 on 2026-08-21 and v4.16.0 on 2026-08-16. The release train is frequent: three minor or patch releases inside roughly three weeks. That cadence is good for fixes and bad for anyone who pins versions and upgrades on a quarterly cycle, because the gap between your version and main grows quickly.

The upgrade cost is shaped by the deployment model. FastGPT runs as a Docker Compose stack, and the README's install script generates the configuration, so an upgrade means pulling new images and reconciling any configuration the new version expects. The README does not document a rollback procedure, and it does not document a migration step for stored knowledge bases or workflow definitions. Before upgrading a deployment that holds data you care about, the thing to verify is what the release notes for the target version say about schema or configuration changes; that information is not in the README.

On licensing, the reported identifier is NOASSERTION and the repository carries a LICENSE file whose terms are not described in the README. The practical implication is simple: read that file before you decide how you will use the software, and if your organisation has a policy on copyleft or source-available licences, route it through whoever owns that policy. Nothing here should be read as legal advice.

The repository also ships a SECURITY.md and an AGENTS.md, and the top-level layout includes .agents/, .codex/ and .forgejo/ directories, which suggests the project maintains tooling for multiple development environments rather than a single editor setup.

Editorial conclusion

Adopt FastGPT if you need a self-hosted knowledge base plus a visual workflow editor plus a chat API in one deployment, and you are willing to run the full Docker Compose stack. Do not adopt it if you only want a retrieval library to embed in your own service, or if you need permissive licensing certainty before shipping. Verify three things first: the contents of the LICENSE file, which features the README marks as unchecked, and whether your deployment target can run the whole Compose stack rather than a single container.

Frequently asked questions

Official sources

1. Issues
2. labring/FastGPT on GitHub
3. Project website
4. README
5. Releases