DocFlow: a block editor with CRDT collaboration and AI writing built in

Notion's flexibility with Feishu's collaboration, block by block

The README is written in Chinese and states the intent directly: a block-level document editor for team collaboration, combining Notion's flexibility with Feishu's collaborative capability. Content is organised as blocks, each an independent editing unit that can be rearranged and nested.

The block system supports more than twenty content types, text, headings, lists, code blocks, tables, images and video among them, and blocks are reordered and re-nested by dragging. That last detail is the one that separates a real block editor from a document with headings.

Collaboration sits on Yjs CRDT, which handles conflicting concurrent edits automatically and gives eventual consistency without a central lock. Paired with the Yjs Awareness module, that produces live cursor tracking and online presence, and the README adds version history rollback on top.

The naming is worth noting for search purposes. The project also runs a hosted service at codecrack.cn, which is a different site from the repository and not clearly a DocFlow deployment. Treat that domain as unverified rather than as an official home page.

The editor stack: Next.js, Tiptap and the App Router

The front end is Next.js on the App Router, using React Server Components for first-paint performance and Server Actions for front-to-back communication, which the README presents as type-safe data flow without a separate API layer.

The editor itself is Tiptap, built on ProseMirror, extended to provide the block-level capability and custom nodes with shortcut commands. This is the right foundation choice for a Notion-like editor, because ProseMirror's document model is a structured tree rather than a string of HTML, which is what makes block manipulation and collaborative editing tractable.

Collaboration runs through Hocuspocus as the Yjs WebSocket server, coordinating sessions, handling client connections and data sync, with an interceptor mechanism providing permission control and persistence.

The whole codebase is TypeScript throughout, with a monorepo layout using pnpm workspaces and Turborepo. `package.json` wires every task through Turbo, so `pnpm dev`, `pnpm build`, `pnpm lint`, `pnpm test` and `pnpm type-check` fan out across workspaces. It also carries husky for git hooks, commitlint and commitizen for conventional commits, and Playwright for end-to-end tests. The `engines` field requires Node `>=24` with pnpm `>=10.28.2`, and `engineStrict` is set to true, so a mismatch fails rather than warns.

Five infrastructure services behind a document editor

This is where the project is unusual. The backend is NestJS with dependency injection for decoupling business logic, and Prisma as the type-safe data access layer with migrations.

Around that sits a full platform stack. Prometheus collects metrics and Grafana visualises them, covering API response time, database query performance and WebSocket connection count, with a dashboard image in the README showing request volume, latency and error rate. Elasticsearch stores and searches log data with Kibana providing analysis and visualisation, filterable by time, level and service module.

MinIO provides object storage for uploaded images and video. RabbitMQ handles asynchronous work such as image compression and email sending so it does not block the main flow.

That is five extra services to operate for what is, on the surface, a document editor. It makes sense if you are running this as a shared team deployment and want operational visibility, and it is a serious maintenance commitment if you are not. Anyone evaluating this should count the containers before the features.

One more detail from the container setup worth knowing: the Docker Compose health check calls `http://localhost:3000/api/health` from inside the container using node, failing if the status code is not 200, with a 30 second interval, a 40 second start period and three retries. Log output is capped at 10 megabytes across three files.

Four AI features and which ones are actually finished

The AI features divide cleanly by how complete they are.

Brainstorming is the most built out. You enter a core concept and the AI generates three to six structured proposals from different angles, each with implementation detail. Results appear as cards with titles and descriptions, and you can insert any of them into the document or refine them further.

Text polishing analyses the structure and expression of a selected passage and offers clearer, more professional rewrites, with an adjustable tone such as formal, concise or friendly.

Continuation writes on from what precedes it, and this is where the engineering is most considered. When the preceding content is long, the system uses RAG to retrieve relevant passages from the document so the continuation stays logically consistent with its context instead of drifting off topic. It also matches the writing style, vocabulary habits and logical structure of the preceding text.

AI chat is the one that is not finished. It currently exists as a standalone page, and the README says it will later be integrated into the editor sidebar with deeper connection to document content. An Agent mode similar to Cursor, able to edit documents automatically, is listed as future exploration.

So when you read the feature list, the honest summary is: three working features, one on the roadmap. The RAG continuation is the one worth examining in the code.

The roadmap contradicts the repository tree

This is the detail to reconcile before you plan an adoption. The future-plans section of the README lists a deep engineering restructuring whose first item is a move to a monorepo architecture based on pnpm workspaces and Turborepo, to separate front and back end code and share type definitions and utility functions.

The repository tree already contains `pnpm-workspace.yaml`, `pnpm-lock.yaml`, `turbo.json`, `apps/` and `packages/`. `package.json` drives every script through `turbo run`. The `packageManager` field pins `[email protected]`, and the `Dockerfile` explicitly copies `apps/DocFlow/package.json` and `packages/bilibili/package.json` before installing, because the workspace layout requires those manifests to exist at their final paths.

So the monorepo migration is either already done and the roadmap text is stale, or the migration is a further step beyond what exists. Either way, do not take the roadmap at face value; read the tree and the container build. That `Dockerfile` detail is the useful tell here, since a build that has to copy workspace manifests before `pnpm install` only works in a workspace layout that is already real.

The rest of the roadmap is more clearly forward-looking: extracting Tiptap extensions like code sandboxes and interactive charts into standalone npm packages with a plugin development specification, integrating LiveKit for real-time audio and video in the collaborative document view, adding a real-time group chat in the sidebar with messages attached to specific blocks, and building a RAG-based private knowledge base over a user's historical documents.

Running it locally or as a container

Local development is four steps. Clone, install, start the dev server, open the browser:

git clone https://github.com/xun082/DocFlow.git
cd DocFlow

pnpm install

pnpm dev

curl http://localhost:3000/api/health

The dev server runs at `http://localhost:3000`, and that health endpoint is the same one the container health check uses, so it is the first thing to verify when something is wrong.

For deployment, the recommended path uses a prebuilt image from GitHub Container Registry:

docker-compose up -d

`docker-compose.yml` pulls `ghcr.io/xun082/docflow:latest`, maps port 3000, sets `NODE_ENV=production` and `NEXT_TELEMETRY_DISABLED=1`, and restarts unless stopped. Building manually is a plain `docker build -t docflow:latest .`, and the `Dockerfile` is multi-arch for linux/amd64 and linux/arm64.

The build itself is worth reading if you want to understand the layout. It runs on `node:24-alpine`, installs `libc6-compat`, enables corepack and activates pnpm 10.28.2, then does a three-stage build: dependencies with `--frozen-lockfile --ignore-scripts`, a builder stage that runs `pnpm turbo run build --filter=DocFlow` and removes the Next.js cache, and a production dependencies stage. The builder sets `NODE_OPTIONS="--max-old-space-size=4096"`, which tells you the build needs headroom.

The contribution requirements are stated in the README and enforced by CI conventions: `pnpm type-check`, `pnpm lint` and `pnpm format` must all pass before a pull request.

Editorial conclusion

DocFlow is a serious piece of engineering with an unusual amount of infrastructure for a document tool: a real observability stack, a proper collaboration server, and a multi-stage container build. If you want to see how block editors and CRDT collaboration fit together in production-shaped code, the repository is worth reading. Two things temper that. The AI features are the shallowest part of it, since the chat currently lives on a separate page and the README says it will later move into the editor sidebar. And the AI chat, AI-assisted editing and the RAG private knowledge base are all described as future work, so do not plan around them. Check three things first: the `engines` field requires Node 24 or newer with `engineStrict` set, which rules out most current LTS deployments; the README describes the monorepo migration as planned even though `pnpm-workspace.yaml`, `turbo.json` and `apps/` already exist, so trust the tree; and the last push was on 2026-03-27 with no tagged releases, so there is no upgrade path to follow yet.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. xun082/DocFlow on GitHub