AppFlowy Web: the browser client for a self-hostable Notion alternative

What AppFlowy Web is, and who it is for

AppFlowy Web is the browser client of AppFlowy, described in the README as the open source Notion alternative. The README lists four use cases: a team knowledge base, published documentation for customers, writing and managing content with AI, and task and project management for a person or a team. The features it names are documents with rich content types, custom Grid and Kanban database views, a Quick Note for lists and to-dos, workspace member invitations, and multiple public and private spaces.

That list tells you who the project is aimed at. It is a workspace product, not a component library, and the repository is one half of a two-part system. The README points to a separate AppFlowy Cloud repository for backend setup and configuration, and states that AppFlowy Web is deployed after AppFlowy Cloud has been set up. If you want a browser-based workspace you can host yourself, this is the front end you would run. If you want a single binary that stores everything locally with no server, this repository is not that thing.

How the web client sits on top of AppFlowy Cloud

The repository layout makes the split visible. There is a deploy/ directory with deploy.env, a dev.env at the top level, a docker/ directory, and a vercel.json. The package.json defines a dev script that runs Vite, a build script that runs vite build, and a dev:server script that runs bun deploy/server.ts. The README's Deployment section says that once AppFlowy Cloud has been set up, you follow the deployment guide to deploy AppFlowy Web.

The data flow implied by that layout is a browser application talking to a separately deployed AppFlowy Cloud instance, with environment files supplying the connection details at build or serve time. The repository has an api/ directory and a src/application/services/js-services/http/ path with integration tests for auth, workspace and user profile, which is where the client-side calls to that backend live. The README does not publish the variable names inside deploy.env or dev.env, so treat doc/DEPLOYMENT.md as the source for those, not this article.

One consequence is worth stating plainly: upgrading the web client and upgrading AppFlowy Cloud are two separate operations, and nothing in the README guarantees that any web build works against any server version.

Installing AppFlowy Web and running it locally

The README gives two installation paths. The cloud path is to sign up for a free account on appflowy.com, which the README calls the fastest way to get started. The self-hosted path tells you to follow the deployment guide at appflowy.com/docs/self-host-appflowy-overview and to ask for help in the project's Discord server.

For local development, the README defers to doc/DEVELOPMENT_GUIDE.md. The package.json shows the tooling: pnpm for dependencies, Vite for the dev server, and Jest for unit tests. Clone the repository and install dependencies first.

pnpm install

Then start the Vite dev server. The script is named dev, and the README's Installation section does not list a port, so read the terminal output for the URL Vite prints.

pnpm dev

To check types before you push anything, the repository provides a type-check script that runs the TypeScript compiler against tsconfig.web.json without emitting files.

pnpm type-check

For a production-style build, run the build script and then preview it on port 3000, which is the port the start script passes to vite preview.

pnpm build
pnpm start

A first real use after that is to open the app in the browser and sign in against an AppFlowy Cloud instance. Without a reachable backend, the workspace features have nothing to talk to, so set up the backend before you judge the client.

Deployment is the part the README leaves to another document

The README's Deployment section is two sentences: once AppFlowy Cloud has been set up, follow the deployment guide to deploy AppFlowy Web. The real detail is in doc/DEPLOYMENT.md, which the Documentation section describes as covering environment configuration, architecture diagrams and troubleshooting. That is the file to read before you plan a rollout, and it is also the file that would tell you which variables deploy.env expects.

What the repository does show is that more than one deployment target is contemplated. There is a vercel.json at the top level, a docker/ directory, and a deploy/ directory containing server.ts, which the dev:server script runs with Bun. So a Docker-based deployment and a Bun-served deployment both appear to be supported paths, and Vercel configuration exists as well. The README does not rank them or say which is recommended, and it does not document a rollback procedure. If you need a documented rollback story, this repository does not provide one in the files listed here.

The absence of version compatibility notes is a real gap. Nothing in the README states which AppFlowy Cloud releases work with which web client releases, even though the release list shows frequent point releases such as 0.16.16, 0.16.18 and 0.17.0 within a few weeks of each other.

Where AppFlowy Web is the wrong tool

The clearest failure mode is deploying the web client without the backend. The README is explicit that AppFlowy Web is deployed once AppFlowy Cloud has been set up, and the architecture it describes is a client against a server. If you are looking for an offline-first, single-user notes application with no server component, the desktop and mobile apps linked from the README are the relevant downloads, not this repository.

Licensing is the second boundary. The project is distributed under AGPL-3.0, and the README points to LICENSE.md in the repository. AGPL-3.0 carries network-use obligations that permissive licences do not, which matters if you intend to modify the web client and expose it to users over a network. That is a question for your own legal review, not something this article can settle, but it is a reason some teams will look elsewhere regardless of the feature list.

The third boundary is scope. This repository is the web front end. It does not contain the backend, and the README sends you to the AppFlowy Cloud repository for that. Anyone who reads "open source Notion alternative" and expects one repository to stand up the whole product will be surprised by the two-repository split.

How it differs from Notion and from the AppFlowy desktop apps

The README frames AppFlowy as the open source Notion alternative, and the feature list maps closely onto that comparison: documents, Grid and Kanban database views, spaces, member invitations. The difference in approach is where the software runs and who controls it. Notion is a hosted service; AppFlowy offers a hosted cloud option at appflowy.com and a self-hosted option where the README says you take charge of your data with no vendor lock-in. That self-hosting path is the substantive difference, and it is also the source of the operational work described above.

The other comparison is inside the AppFlowy family. The README links a Web entry alongside an Apps download page and points to appflowy.com/download. The desktop and mobile apps are separate distributions from this repository. Choosing the web client means choosing a browser tab over an installed application, and accepting that the browser client depends on a reachable AppFlowy Cloud instance in a way the installed apps may not. The README does not document how offline behaviour differs between them, so if offline use matters to you, that is a question to answer from the official documentation rather than from this repository.

Maintenance, releases and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-28. Releases are frequent and small: 0.16.16 on 2026-08-15, 0.16.18 on 2026-08-16, and 0.17.0 on 2026-08-28. A cadence of point releases every day or two suggests active work, but it also means the version you pin will fall behind quickly if you do not track it.

The upgrade cost is dominated by the backend pairing, not by the front-end build. Because AppFlowy Web is deployed against an already-running AppFlowy Cloud, every web upgrade is a chance to move out of step with the server. The README does not publish a compatibility matrix, so the practical procedure is to read the release notes for the version you are moving to, check doc/DEPLOYMENT.md for environment changes, and rebuild from the pinned commit. The build itself is a Vite build behind the pnpm build script, which is cheap; the verification around it is not.

On licensing, the repository states AGPL-3.0 and points to LICENSE.md. If you self-host a modified web client for other people to use over a network, read that file and get your own advice. Nothing here should be read as legal guidance.

Editorial conclusion

AppFlowy Web suits teams that already run AppFlowy Cloud and want the workspace reachable from a browser without installing the desktop app, and anyone evaluating a Notion alternative who accepts an AGPL-3.0 licence and a separate backend. It is the wrong choice if you have no AppFlowy Cloud deployment, because the repository states the web client is deployed only once that backend is set up. Before adopting it, read doc/DEPLOYMENT.md for the environment variables, confirm your AppFlowy Cloud version matches the web client you build, and check LICENSE for what AGPL-3.0 means for your distribution.

Frequently asked questions

Official sources

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