What was released
On 29 September 2026, the RAGFlow team published the v1.0.0-rc1 preview. According to the official release notes, the server side has been rewritten in Go: NATS replaces Redis as the message queue, while Kvrocks backs the cache and checkpoints. The developers say the change substantially reduces system resource consumption, but the notes do not provide a universal figure that can be applied to every company's documents and model workload. This is a release candidate, not a signal to upgrade a production installation automatically.
For a small or medium-sized business, the practical relevance is a local document RAG stack that can be trialled on a separate server. The official quick start recommends 4 CPU cores, 16 GB of RAM and 50 GB of disk as a starting configuration; actual needs depend on data volume and workload. Local language and embedding models need additional resources. The supported native Go image targets Linux x86-64, which should be checked before allocating or buying hardware.
The upgrade risk
The most important qualification appears in the release notes: when the new container starts, data from a 0.27.2 installation is migrated automatically to the 1.0 RC1 format, and a return to 0.27.2 is not supported afterwards. The project recommends backing up data in advance and verifying recovery. If production search depends on document collections, chats or integrations, the safe route is a copy of the data on a separate test environment, not an experimental start of the new container against production volumes.
There are functional gaps too: deprecated APIs are no longer supported by the Go implementation, the local sandbox is absent, the Team/Me permission model is not yet implemented, and DeepDoc runs on CPU in this release. The project says the Python SDK remains unaffected, but custom HTTP API calls and access-control scenarios still need separate checks. For a shared knowledge portal with distinct user groups, the missing permission model may be a stop condition.
What RAGFlow users should do
Teams already running 0.27.2 should first list their dependencies: document sources, search engine, API calls, user roles, and index size. Then restore a backup in an isolated environment and measure more than whether the service starts: answer quality on a familiar question set, document-processing time, memory use, and access-control behaviour. Without a separate test environment or a recovery procedure, RC1 is better reserved for a lab trial.
For teams choosing a local RAG stack for the first time, the release provides a pilot candidate, not a ready-made business case. Compare it with ordinary search over approved documents and include the cost of maintaining infrastructure, models and upgrades. A rewrite in Go alone does not prove cost savings in your workflow.