AppFlowy: the open source Notion alternative you can self-host

What AppFlowy replaces, and for whom

AppFlowy is a workspace application for project management, wikis and team collaboration, positioned by its README as "The Open Source Alternative To Notion". The stated motivation is concrete: the team used Notion on a paid plan and ran into what the README calls weak data security and poor compatibility with mobile devices. The project's answer is to keep the document-and-database model but let the user hold the data.

The audience is split in two by the README itself. Individuals are offered Notion-like functionality with a native cross-platform experience. Enterprises and developers are offered "building blocks and collaboration infra services" so they can assemble their own apps, with the README claiming 100 percent control of the data. Those are different products sharing one codebase, and the second audience is the one that actually justifies the project's existence.

If you only want a place to write notes, the README's own framing is worth taking at face value: it says the project does not claim to outperform Notion in functionality and design, and that more functionality is not the current priority. That is an unusually direct statement of scope from a project of this size, and it should shape your expectations before you migrate anything.

Flutter on the front, Rust underneath

The stack is stated plainly in the README: Flutter for the interface, Rust for the rest. The repository layout matches that split, with a top-level frontend/ directory alongside build and translation configuration files such as codemagic.yaml, project.inlang.json and commitlint.config.js. The README describes a single codebase supporting multiple platforms, which is why the same project produces desktop builds and mobile apps.

What the README does not give is a data flow diagram, a storage format description, or any detail on how a self-hosted server syncs with a client. If you need to reason about where documents live on disk, or how a conflict is resolved when two devices edit the same page offline, the README will not tell you. The self-hosting guide is the place to look, and it is linked rather than reproduced.

Translation is the one subsystem with documented mechanics. The README says translations live as JSON files under /frontend/resources/translations, and that you can edit them by hand, through the inlang online editor, or by running a machine translation command. That is a real, checkable workflow, and it is more than the README offers for storage or sync.

Installing AppFlowy and opening a first workspace

The README's user installation section lists packaged downloads rather than build instructions. Desktop builds for macOS, Windows and Linux are published on the GitHub releases page, and the README also names FlatHub, Snapcraft and Sourceforge as alternative channels. Mobile builds come from the App Store for iPhone and the Play Store for Android.

On Linux, FlatHub and Snapcraft are the two channels the README names, and it links to each listing rather than reproducing an install command. The README gives no command line for either channel, so the honest first step is to open the linked listing and follow the instructions there. The README does not give a version pin or a checksum for either channel, so what you get is whatever the channel currently serves.

After install, the app opens into a workspace; the README does not document a first-run wizard, an account requirement, or a sample document, so treat the first launch as something to observe rather than something to follow in the docs.

If you would rather build it yourself, the README sends you to the from-source documentation at docs.appflowy.io and says OS-specific development instructions live there. The repository also contains an install.sh at the top level, but the README does not describe what it does, which arguments it takes, or which platforms it supports. Read the script before running it.

The mobile story has a hard floor

Android support starts at Android 10, and the README states that ARMv7 is not supported. That is not a soft recommendation; it excludes a class of older and low-cost devices outright. If your team includes people on budget Android hardware, they are outside the supported set, and the README offers no workaround.

The iOS side is delivered through the App Store, which means the mobile client is not something you self-host or sideload from the repository. Your documents may live on your own server, but the client binary on an iPhone comes from Apple. For an organisation that chose AppFlowy specifically to avoid third-party distribution, that is a gap worth noticing before rollout rather than after.

The README also flags mobile compatibility as one of the reasons the team left Notion. Given that, the Android 10 floor and the ARMv7 exclusion read as an admission that the problem is being worked on rather than solved. There is no statement in the README about when, or whether, those constraints will move.

Self-hosting versus the desktop download

AppFlowy offers two deployment shapes that are easy to confuse. The first is the packaged desktop app, which the README presents as the default for individuals. The second is self-hosting, for which the README links a single guide titled "Step-by-step Self-Hosting Guide - From Zero to Production". That title implies a server, a database and a production configuration, but the README itself supplies none of those details: no container image name, no port, no environment variable, no compose file.

The repository does carry a .dockerignore at the top level, which suggests container-based deployment is part of the workflow, but the README never mentions Docker and the self-hosting guide is the only documented path. Anyone searching for an AppFlowy Docker setup will find the guide, not the README.

This matters because the two shapes have different upgrade stories. A desktop user replaces an app. A self-hoster runs a server that other people's clients depend on. The README documents neither upgrade path, so the cost of running AppFlowy for a team sits mostly in the operations you will have to figure out from the guide.

Where AppFlowy is the wrong tool

The licence is the first constraint. AppFlowy is distributed under AGPL-3.0, and the README points at LICENSE.md for the full text. If you plan to modify AppFlowy and offer it to users over a network, the AGPL's source-disclosure terms are the thing to read before you write code, not after. That is a statement about the licence's scope, not legal advice, and the LICENSE.md file is the authority.

The second constraint is documentation depth. The README is a landing page: it links to a website, a forum, a Discord, a Reddit community and a Twitter account, and it delegates development, self-hosting, roadmap and changelog content to external pages. If your adoption decision depends on reading a specification in the repository, you will not find one. The doc/ directory exists, but the README does not describe its contents.

The third is fit. The README explicitly says the project does not claim to beat Notion on functionality and design, and that its priority is not more functionality. If your team needs the breadth of an established commercial workspace today, AppFlowy is asking you to trade features for control. That trade is the whole point, but it is a trade, and the README is honest about which side you are giving up.

How it differs from Obsidian and Affine

The most common comparison is with Notion, and the README frames the difference as data control plus a native cross-platform client rather than a feature race. Notion is a hosted service; AppFlowy's self-hosting path puts the server on infrastructure you choose. That is the actual delta, and everything else follows from it.

Obsidian takes a different route to the same goal. It is a local-first notes application built around plain files on your disk, so portability comes from the file format rather than from running a server. AppFlowy is a collaborative workspace with databases and team features, which means it needs a synchronisation layer that a file-based notes tool does not. If your problem is personal note-taking, the server is overhead you do not need.

Affine is the closer comparison: another open source workspace aiming at the same Notion-shaped territory. The README does not discuss Affine, so there is no project-stated difference to quote. The honest position is that both are open source collaborative workspaces, and the deciding factors will be the licence terms, the deployment model and the mobile support each one documents. AppFlowy's documented mobile floor is Android 10 with no ARMv7, which is a concrete point of comparison you can check against whatever Affine publishes.

Releases, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-08-28, the same day as the 0.14.0 release. Two patch releases, 0.13.1 and 0.13.2, landed earlier in August 2026. That cadence is visible in the release list, and the README points to a changelog page for release details rather than keeping them in the repository.

What the README does not document is rollback. There is no statement about whether a workspace created in 0.14.0 can be opened by 0.13.2, no migration command, and no backup procedure. For a desktop user that risk is contained; for a self-hoster running a shared server, it is the largest unquantified cost in the project. Before upgrading a production instance, the changelog is the only documented source, and it is external to the repository.

On licensing, AGPL-3.0 governs the code, and LICENSE.md is the file to read. The practical implication for most teams is that internal use carries no distribution obligation, while exposing a modified version as a network service does. Whether your specific deployment crosses that line is a question for your own reading of the licence, not for this article.

Editorial conclusion

Adopt AppFlowy if you want a Notion-shaped workspace whose data you host yourself, and you accept the AGPL-3.0 obligations and a mobile client limited to Android 10 or above. Do not adopt it if you need a documented rollback path or a supported upgrade procedure; the README links to a changelog page but does not describe either. Verify first that the self-hosting guide covers your deployment target, and check the changelog for 0.14.0 before moving an existing workspace onto it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes