AppFlowy AGPL archived: Docmost, the only Notion alternative left

AppFlowy had two distinct parts: the client application (Flutter + Rust, still active) and AppFlowy-Cloud, the multi-user collaboration server. It is this second repository — AppFlowy-IO/AppFlowy-Cloud — that was archived on September 11, 2026 by the organization.

The organization now directs users to AppFlowy-SelfHost-Commercial: a repository whose codebase is proprietary. You can still deploy AppFlowy as a server, but no longer under a free license. This is not a license change on the same code: it is a closed commercial fork that replaces the public repository.

For teams that cited the AGPL license as a deployment condition — compliance requirements, IT policy, client contracts — that argument disappears overnight. And for those who chose AppFlowy specifically because an organization shutting down would not leave users stranded, the irony is real: the piece that manages team collaboration is no longer auditable.

Docmost is a collaborative knowledge base published under AGPL-3.0 on github.com/docmost/docmost. Its distribution model resembles what AppFlowy once promised: a fully free core, with opt-in commercial extensions for large organizations.

The Open Source edition covers the essentials: hierarchical spaces and pages, real-time collaborative editing, comments, version history, granular space permissions, and RTL support (added in v0.96.0 — September 2026). No member caps, no features locked behind a paywall in the base edition.

Business and Enterprise editions add audit, DOCX export, and governance features for teams that need them — but they layer on top of an Open Source base that remains complete. The AGPL-3.0 license on the core requires any network service operator who modifies the code to publish those modifications: this is the guarantee that the server code handling your documents remains auditable.

A common argument in discussion threads: the main AppFlowy-IO/AppFlowy repository — the desktop and mobile application — is still active. That is true. But this argument conflates the client layer and the server layer.

In a team deployment, the server handles authentication, data synchronization, permissions, and page storage. It is the component that receives your documents. It is the component that enforces access rules. The client application, however open source, does not change the nature of the component it communicates with.

Staying on the last AGPL commit of AppFlowy-Cloud means: no future security fixes, progressive incompatibilities with the client (which keeps evolving), and an unmaintained codebase. This is the definition of short-horizon technical debt.

AppFlowy and Docmost do not share a native common export format. The cleanest migration goes through Markdown export from AppFlowy (available from the client interface) and import into Docmost. Images and file attachments require separate handling.

Docmost handles Markdown file imports and hierarchical page structures. For large volumes, bulk import via the API is the most reliable path.

Four things to check before switching: the structure of your AppFlowy spaces (one space = one Docmost space), third-party integrations connected to AppFlowy-Cloud (webhooks, automation scripts), group-based permissions, and users without a verified email who will not pass Docmost's standard invitation flow.

AppFlowy is not the first project to take this step. The pattern is documented: a tool starts under a permissive or copyleft license, gains popularity, raises funding, and progressively reserves the server code. What this archiving illustrates is the limit of the open-core model when the commercial core is the server.

The distinction that matters for a technical lead: a project whose publisher draws revenue from the server license has a direct interest in making that server difficult to replace. A project whose publisher draws revenue from Enterprise editions — built on a stable open source core — has an interest in keeping that core in good shape. This is the tension AGPL attempts to reduce: by requiring publication of modifications, it makes the core harder to close.

Docmost follows the second model. Its AGPL core is the foundation on which teams choosing to self-host place their trust. Removing that foundation would destroy the value proposition the project sells to its Business and Enterprise customers.

Docmost has been stable in production since late 2025. A few things to know before a team deployment.

Backups: data lives in PostgreSQL and in the file storage volume. An automated daily backup of both is sufficient. pg_dump scheduled via cron, and rsync or an S3 snapshot for attachments.

Updates: Docmost publishes regular releases — approximately one per month in 2026. The procedure is a docker compose pull followed by docker compose up -d. Schema migrations are applied at startup. Read release notes before updating: some versions introduce non-reversible migrations.

SSO authentication: Docmost supports SAML 2.0 and OIDC in Business and Enterprise editions. The Open Source edition handles email-based authentication and invitations. For teams with an LDAP/AD directory, the Business edition is required.

Performance: on 2 vCPU / 4 GB RAM, Docmost comfortably handles 20 to 50 simultaneously active members. Beyond 100 members with heavily used spaces, plan for 4 vCPU / 8 GB and a dedicated PostgreSQL node.