Anytype Desktop: a local-first knowledge OS you build from source with bun and anytype-heart

The problem Anytype Desktop solves, and who it is actually for

Most note tools ask you to trust a server. Anytype Desktop takes the opposite position: the README describes it as a "Local-first, peer-to-peer & end-to-end-encrypted knowledge OS for macOS, Windows & Linux," and the repository topics list e2ee, local-first, offline-first, p2p and privacy. In practice that means your pages, tasks, wikis, journals and databases are written to local storage first, and network sync is an optional layer on top rather than the place the data lives.

The second half of the pitch is the data model. The README says you can "define your own data model" and build with "Composable blocks: text, databases, kanban, calendar & custom Types." That is a different proposition from a folder of Markdown files. A Type in Anytype is a schema you define, and objects of that Type can be viewed as a kanban board, a calendar or a table without exporting anything. If you have ever kept the same project in a notes app, a task tracker and a spreadsheet, the appeal is obvious.

The audience is narrower than the marketing suggests. This is a desktop client for people who want a personal knowledge base with an explicit schema and who are comfortable with a binary engine running underneath. It is not a team wiki with server-side permissions, and it is not a text format you can grep.

How the Electron client talks to anytype-heart

The repository is TypeScript and Electron, but it does not contain the storage engine. The README is explicit that the middleware is a separate project: step 4 of the build clones anyproto/anytype-heart and runs make install-dev-js CLIENT_DESKTOP_PATH=../anytype-ts. The desktop client is the interface; anytype-heart is the engine that owns encryption and sync.

The connection between them is gRPC. The README lists "Extensible through a gRPC API and AI 'Agents'" as a feature, and the build notes explain that step 5 generates "protobuf bindings (middleware/) + service registry (src/ts/lib/api/service.ts)." So the data flow is: the Electron UI calls a generated TypeScript client, that client speaks gRPC to the middleware binary, and the middleware handles local storage and the any-sync protocol that the README credits for "Zero-knowledge encryption."

Two consequences follow. First, the generated bindings are git-ignored. A fresh checkout has neither middleware/ nor src/ts/lib/api/service.ts, and the README warns that skipping the generation step causes Failed to resolve import "./service" from src/ts/lib/api/dispatcher.ts. Second, the middleware version is pinned in a file called middleware.version, so the client and the engine are versioned separately. That is a sensible design for a cross-platform app, but it means a build problem can sit in either repository.

Installing Anytype Desktop without compiling anything

The README's Quick Start is deliberately short: "Grab the latest installer from the releases page or head to download.anytype.io and log in with your Any-ID." If you only want to use the app, that is the whole procedure. There is no package manager install documented for the desktop client, and no Homebrew formula or apt repository appears in the README. The releases page carries the builds, and the most recent listed release is v0.56.11-beta, published on 2026-09-19.

Note the version suffix. The releases in the repository are v0.56.11-beta, v0.56.10-beta and v0.56.9-alpha. Anyone who needs a stable channel should read that as a statement about the project's release cadence rather than assume a long-term support branch exists.

After installing, you log in with an Any-ID. The README does not document account creation, recovery phrases or what happens if you lose access to that identity, so treat identity management as something to investigate in the app itself rather than in this repository.

Building the desktop client from source, step by step

Building requires bun, a C++ compiler, Python 3 and setuptools on ARM systems because the keytar package is rebuilt during install. On Debian or Ubuntu the README suggests installing python3-setuptools, or creating a virtual environment and running pip install setuptools inside it. Linux additionally needs the protobuf compiler with the well-known .proto files: sudo apt install protobuf-compiler libprotobuf-dev jq on Debian and Ubuntu, or sudo dnf install protobuf-compiler protobuf-devel jq on Fedora.

The first two steps clone the repository and install JavaScript dependencies with bun:

git clone https://github.com/anyproto/anytype-ts.git && cd anytype-ts
bun install

Step 3 fetches a prebuilt middleware binary plus its proto and JSON assets into dist/. The argument pair selects the platform and architecture:

./update.sh <macos-latest|ubuntu-latest|windows-latest> <arm|amd>

Step 4 builds the core engine from the sibling repository. The path passed to CLIENT_DESKTOP_PATH is what lets the heart build write back into this checkout:

cd .. && git clone https://github.com/anyproto/anytype-heart.git && cd anytype-heart
make install-dev-js CLIENT_DESKTOP_PATH=../anytype-ts && cd ../anytype-ts

Step 5 generates the protobuf bindings and the service registry. The README gives an alternative that skips the anytype-heart checkout entirely by generating from the assets fetched in step 3:

bun run generate:protos
bash scripts/generate-protos.sh --from-dist

Then update locales and produce a package for your platform. The README points at package.json for the full set of options:

bun run update:locale
bun run dist:<linux|win|mac>

If you would rather work in the dev loop than produce an installer, bun run start:dev builds the Electron bundle, starts Vite and launches Electron; closing Electron stops the Vite server. The Vite port defaults to 8080 and can be overridden with the SERVER_PORT environment variable. Two environment flags matter for local builds: ELECTRON_SKIP_NOTARIZE skips macOS and Windows signing and notarizing, and ELECTRON_SKIP_SENTRY stops sourcemap uploads to Sentry.

Where the source build bites you

The generated-artifacts requirement is the sharpest edge. Because middleware/ and src/ts/lib/api/service.ts are git-ignored, the failure mode for a missed step is not a missing binary but a module resolution error inside the TypeScript build. The README names it exactly: Failed to resolve import "./service" from src/ts/lib/api/dispatcher.ts. If you see that string, the answer is step 5, not a dependency problem.

The second constraint is that this repository alone is not buildable for development. Step 4 expects anytype-heart at ../anytype-heart, or you take the --from-dist route and accept whatever assets update.sh downloaded. That is a real coupling: a change in the middleware's proto definitions can require regenerating bindings here, and the two projects are released on their own schedules. The README even has a dedicated Updating Middleware section that downloads the anytype-heart release matching the version in middleware.version, which tells you the pin is the contract.

A third point is that the README does not document rollback, downgrade or data migration between middleware versions. If you build from source and move between middleware builds, the repository gives you no procedure for going backwards. That is a limitation worth knowing before you point a build at a knowledge base you care about.

Anytype vs Obsidian: same folder, different bet

The comparison people reach for is Anytype vs Obsidian, and the difference is not cosmetic. Obsidian's model is files on disk in a folder you choose, with Markdown as the storage format; plugins read and write those files, and you can open the vault with any text editor. Anytype's model is objects and Types managed by the middleware, with encryption and peer-to-peer sync built in from the start. The README's feature list puts "Offline-first, local storage with optional peer-to-peer sync" and "Zero-knowledge encryption" in the same breath, which is the part Obsidian does not attempt natively.

That trade runs both ways. Anytype gives you a schema system and encrypted sync without a third-party service in the middle. It does not give you plain files. If your workflow depends on scripting over Markdown, on Git as your version history, or on opening the same notes in an editor that knows nothing about Anytype, Anytype is the wrong tool and no amount of configuration in this repository changes that. Conversely, if you have been bolting encryption and sync onto a Markdown vault with a plugin stack, Anytype is the version where those are the foundation.

Licence, maintenance and the cost of staying current

The licence is not a standard open source licence. The README badge reads ASAL-1.0 and the License section points at LICENSE.md, while the repository metadata reports NOASSERTION. The README describes the code as "Open code under the Any Source Available License 1.0" and the badge text says license-ASAL-1.0. Source-available is not the same as OSI-approved open source, and the practical difference is in what LICENSE.md permits for redistribution and derivative works. Read that file rather than assuming MIT or Apache terms apply; nothing here should be read as legal advice.

On activity, the last push to the default branch develop was on 2026-09-19, and the newest release, v0.56.11-beta, was published the same day. The repository is not archived. The release names carry alpha and beta suffixes, so the upgrade cost is the ordinary one for a fast-moving client: you are tracking a moving target, and the middleware pin in middleware.version is the thing that has to stay consistent with whatever the client expects.

Upgrade cost for source builders is concentrated in two commands. ./update.sh re-fetches the middleware binary and its proto assets, and bun run generate:protos (or the --from-dist variant) regenerates the bindings that the build needs. If you build once and then stop, expect the next build after a middleware change to fail at the service import until you regenerate.

Editorial conclusion

Adopt Anytype Desktop if you want a personal knowledge base whose pages, databases and custom Types live on your disk first, and you accept that the desktop client is one half of a two-repository system. Skip it if you need a plain Markdown folder you can read with any editor, or if you want a server you can point at your own domain today. Before committing, verify three things: that the installer for your platform exists on the releases page, that middleware.version matches an anytype-heart release you can fetch, and that the ASAL-1.0 terms in LICENSE.md are acceptable for how you intend to use the code.

Frequently asked questions

Official sources

1. anyproto/anytype-ts on GitHub
2. Issues
3. Project website
4. README
5. Releases