Notesnook: an end-to-end encrypted note app you can build from source

What Notesnook solves, and for whom

Most note apps ask you to trust a server operator with plaintext. Notesnook takes the opposite position: the README states that everything is encrypted on your device using XChaCha20-Poly1305 and Argon2, and that the project is built around zero knowledge principles. The pitch is an Evernote-shaped product where the vendor cannot read your notes.

The intended audience is narrower than the download page suggests. This is for people who care whether the crypto is real and are willing to check. The README points to Vericrypt, a separate site whose stated purpose is to let users verify Notesnook's encryption claims themselves. A project that builds a verification tool for its own claims is telling you what kind of user it wants.

The second audience is developers. The repository is a monorepo containing the web, desktop and mobile clients, a shared core, a crypto wrapper around libsodium, an editor, a web clipper, a logger, a theme package and a streaming filesystem. If you want to embed a note editor or a crypto layer in your own product, the packages are exposed under the @notesnook scope. If you just want a notes app, you can ignore all of that and download a build.

How the monorepo is put together

The architecture is layered, and the layering is the interesting part. @notesnook/crypto wraps libsodium, and @notesnook/sodium wraps libsodium again to work in both Node.js and the browser. That second wrapper exists because the same crypto code has to run in an Electron process, a browser tab and React Native.

@notesnook/core is described as the shared core between all platforms. Above it sit the clients: @notesnook/web, @notesnook/desktop and @notesnook/mobile. The editor is its own package, with @notesnook/editor-mobile described as a thin wrapper around @notesnook/editor. Clipping is split the same way, with @notesnook/clipper handling page clipping and @notesnook/web-clipper being the browser extension.

The stack is React across all front ends, React Native for mobile and Electron for desktop. The README is explicit that the repo is in a hybrid state: newer code is TypeScript, older code is being ported over. That matters if you plan to read the source. You will find both styles, and the older files will not match the conventions in CONTRIBUTING.md.

One deliberate choice stands out. The README states that the project does not use Yarn or PNPM, only NPM. In a monorepo of this size that is a constraint, not a preference, and it means the lockfile you should trust is package-lock.json.

Installing Notesnook and making a first note

For most readers the install is a download. The README links to notesnook.com/downloads, and the release list shows separate version lines per platform, for example Notesnook Desktop v3.4.6 and Notesnook Android v3.4.10. Pick the build that matches your platform rather than assuming one version number covers everything.

If you want to run the web client from source, the repository is an NPM monorepo. The root package.json defines a bootstrap script that is also wired into prepare, so a plain install pulls in the workspace setup:

npm install
npm run bootstrap

The prepare hook runs husky install and then bootstrap, so the second command is redundant after a normal install but harmless if you cloned without running hooks.

To start the web client in development, the root scripts expose a wrapper that dispatches into the workspace:

npm run start:web

The desktop client has its own entry point, and the mobile clients have separate ones for Android and iOS:

npm run start:desktop
npm run start:android
npm run start:ios

On iOS, the README's script list includes a separate step for CocoaPods before building, exposed as prepare:ios. Run that before build:ios or the native build will not have its dependencies.

When the client opens, the first real action is creating an account, because the README's own resources include an explanation of why Notesnook requires an email address. After that, the useful first test is not writing a note. It is exporting one. If you can export and read your own data, the encryption is not locking you in.

Where Notesnook is the wrong tool

The repository contains clients, and the README describes it that way: all the code required to build and use the web, desktop and mobile clients. It does not describe a server you can host. There is a servers/ directory in the top-level listing, but the README does not document deploying it, and there is no self-hosting guide among the linked resources. Anyone searching for a self-hosted Notesnook should treat that as unresolved until they find documentation that says otherwise.

The second limitation is the hybrid codebase. A project mid-port from JavaScript to TypeScript is harder to contribute to than one that finished. The README names the state plainly, which is honest, but it means the style guide in CONTRIBUTING.md will not describe every file you open.

The third is the platform split. Releases are versioned per platform, as the Android and desktop tags show. A feature you read about may land on one client before another, and the monorepo structure does not imply synchronized shipping.

Finally, encryption has a cost that the README does not discuss: search, sync and sharing all have to work on ciphertext or on decrypted local state. The README does not document how server-side search behaves, so if full-text search across a large account is your main use, test it on your own data before migrating.

Notesnook against Joplin and Obsidian

The closest comparison in the search data is Joplin, and the difference is architectural. Joplin is built around sync targets you choose, including your own WebDAV or Nextcloud server, with end-to-end encryption applied on top of that sync. Notesnook's README describes encryption on the device as the foundation and does not describe a bring-your-own-sync-target story. If owning the storage server is the requirement, Joplin's model matches it more directly; if the requirement is that the service operator never holds plaintext, Notesnook's model is the one stated in its README.

Obsidian is a different axis entirely. Obsidian works on local Markdown files in a folder you control, and its value comes from plugins. Notesnook's editor is its own package with its own extensions, and notes are not described as plain files on disk. Migrating out of Obsidian means converting Markdown into Notesnook's importer; migrating out of Notesnook means exporting. Neither is wrong, but the file-on-disk model is easier to walk away from.

Standard Notes also appears in the search data and is the nearest philosophical match: open source, encryption-first, clients on multiple platforms. The practical difference for a reader is packaging and governance rather than cryptography. Both projects ask you to trust a client implementation, which is why Notesnook shipping Vericrypt as a separate verification site is the detail worth weighing.

Licence, maintenance and what upgrades cost you

Notesnook is GPL-3.0. For anyone running the app, that is unremarkable. For anyone embedding @notesnook/core or @notesnook/editor into a product, it matters: GPL-3.0 is a copyleft licence, and the obligations attach to distribution. The README does not offer an alternative licensing path, and this is not legal advice, so if you plan to ship a derivative work, read LICENSE and talk to a lawyer rather than assuming the package scope implies permission.

The repository is not archived, and the last push was on 2026-08-25, which is recent enough to call the project active. Releases are frequent and split by platform: Notesnook Android v3.4.10 on 2026-08-25, Notesnook Desktop v3.4.6 on 2026-08-17, Notesnook Android v3.4.9 on 2026-08-10. That cadence is a maintenance cost as much as a signal. If you build from source, you are tracking a moving monorepo whose mobile and desktop lines advance separately.

Upgrade cost depends on how you consume it. As an app user, upgrades are the vendor's problem. As a source builder, every pull means re-running bootstrap, and the hybrid JavaScript and TypeScript state means a version bump can touch files in either style. The README does not document a rollback procedure for either case.

Editorial conclusion

Adopt Notesnook if you want client-side encryption you can inspect, a cross-platform client set, and a codebase you are willing to build yourself. Do not adopt it if you need a self-hosted sync server, because the repository ships clients while the sync service remains Notesnook's own. Before committing, verify two things: that the release you intend to run exists for your platform, and that the importer covers the export format of the app you are leaving.

Frequently asked questions

Official sources

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