# Standard Notes: self-hosting the encrypted notes app from standardnotes/app

> Standard Notes is an end-to-end encrypted notes and files app, and standardnotes/app is the TypeScript monorepo behind its web, desktop and mobile clients. The repository is public and AGPL-3.0, but the README documents the web client and the sync server address, not the server itself.

**standardnotes/app** — Think fearlessly with end-to-end encrypted notes and files. For issues, visit https://standardnotes.com/forum or https://standardnotes.com/help.

- Repository: https://github.com/standardnotes/app
- Website: https://standardnotes.com
- Stars: 6,636 · Forks: 555
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/standardnotes-app

## What standardnotes/app actually is, and who it is for

The repository is not the product. It is the client monorepo: a Yarn workspaces tree with a Lerna release config, whose packages produce the web app, the desktop app, the mobile app, the shared snjs library, the services layer and the API package. The README describes the product as an end-to-end encrypted note-taking app for digitalists and professionals, and the four bullets it leads with are encrypted sync, free cross-platform sync on unlimited devices, public source with self-hosting, and a stated focus on longevity.

The audience that benefits most is narrow. If you want to read the client code that handles your notes, build a web bundle and serve it yourself, or set the default sync server your users log into, this repository is the entry point. If you want a notes app to install and forget, the README's own onboarding path never mentions this repository at all: it tells you to launch app.standardnotes.com, click Register, and download the desktop or mobile build from the download page. Cloning is for people who want to change or host the client, not for people who want notes.

## How the monorepo is wired and where the sync server fits

Everything runs through Yarn workspaces. The root package.json declares packages/* as the workspace glob, and every build script is a workspace fan-out: build:web, build:desktop, build:mobile, build:snjs, build:services and build:api each resolve a target package and build its dependency graph first. The -R flag on those scripts is what pulls in dependencies, so building the web client also builds whatever it depends on rather than assuming prebuilt artifacts.

The one runtime knob the README documents is the sync server. DEFAULT_SYNC_SERVER sets the default server used for login and registration, and .env.sample ships it as https://api.standardnotes.com alongside PORT=3001 and three subscription-related URLs (DASHBOARD_URL, PLANS_URL, PURCHASE_URL). That is the seam between client and backend: the client is a static bundle, and the server it talks to is configuration. The README links to a self-hosting getting-started guide for running your own server, but that guide is on the help site, not in this repository, so nothing here tells you what the server must implement.

Node version is pinned by the engines field to >=12.19.0 <17.0.0. That is a hard constraint, not a suggestion: a current Node release will not satisfy it, and Yarn will complain.

## Building and serving the web app: a first run

The README gives a five-step path for serving the compiled web app as static files. Clone, install, build, then serve the output folder. The build is a workspace fan-out, so expect it to build dependencies before it builds the web package.

```bash
git clone https://github.com/standardnotes/app.git
cd app
yarn install
yarn build:web
cd packages/web
```

After yarn build:web finishes, packages/web holds the compiled HTML, JS and CSS. The README suggests Python for a quick local check: python -m http.server 8080, after which the app is reachable at http://localhost:8080. That is a static file server, so it is fine for a smoke test and not a deployment story.

For iterating on the client, the README gives a separate development path that ends on port 3001:

```bash
cd packages/web && yarn start
```

Open http://localhost:3001. To point a build at your own backend instead of the default, set the environment variable the README documents. The .env.sample file shows the same key with the hosted API as its value, so the shape is confirmed by two sources in the repository:

```bash
DEFAULT_SYNC_SERVER=https://sync.myserver
```

What you should see: the web client loading and offering registration and login against whichever server that variable names. If login fails against a self-hosted address, the client is working and the server is the variable to check, because the README documents the client side of that connection and nothing about the server.

## The self-hosting gap the README does not close

The README's self-hosting section is titled "Self-hosting the web app", and that wording is precise. It covers serving static client files. It does not cover the sync server, the database, accounts, subscription endpoints, or upgrades. The bullet list promises you can self-host your own server "in a few easy steps" and links to https://standardnotes.com/help/self-hosting/getting-started, which means the instructions live outside the repository you just cloned.

That split has consequences. The env sample names DASHBOARD_URL, PLANS_URL and PURCHASE_URL, so a self-hosted deployment is expected to have opinions about subscription flows, and nothing in the repository explains what a self-hosted instance should point those at. If your goal is a fully self-contained encrypted notes stack, this repository is one half of it, and the half you are missing is documented elsewhere.

The second limitation is the toolchain. Node is capped below 17.0.0, and the build is a topological workspace fan-out, so a cold yarn install followed by yarn build:web pulls the whole dependency graph. There is a reset script that deletes every node_modules directory and yarn.lock and reinstalls, which tells you the maintainers expect dependency state to go bad often enough to need a one-liner. If you wanted a small, quick-to-compile client to embed in another product, this is the wrong shape.

## Compared with a plain Markdown folder in a Git repository

The obvious alternative for someone who only wants encrypted notes is not another app; it is a directory of Markdown files in a private Git repository, optionally encrypted at rest by the hosting provider. The difference is where the encryption boundary sits. With files in a repository, the server stores plaintext and your access control is the repository permission model. With Standard Notes, the client encrypts before sync, and the sync server is a transport for ciphertext, which is why the README can say only you can read your notes and why self-hosting the client and pointing it at a different server is a supported configuration rather than a rewrite.

What you give up is the filesystem. Notes live in the app's own model, editable through the clients and through extensions, not as files you can grep or edit in any editor. The README points developers at a plugins documentation hub for building extensions, and mentions Listed for publishing notes as an online publication with email newsletters. Neither of those gives you a plain directory of .md files. Choose the repository-of-files approach if portability of the raw text matters more than the encryption boundary; choose this if the encryption boundary is the point.

## Licence, releases and what maintenance costs you

The repository is AGPL-3.0. For a client application that you build and run for yourself, that is unremarkable. For a modified build that you serve to other people over a network, the AGPL's network clause is the part that matters, and it is the reason a company might fork the client internally rather than ship a hosted derivative. This is not legal advice; read the LICENSE file in the repository and get your own answer.

Releases are frequent and per-package, not per-repository. The recent list shows @standardnotes/mobile@3.202.7, @standardnotes/desktop@3.202.7 and @standardnotes/clipper@1.1.602, all dated 2026-09-17, which means the mobile and desktop clients move in lockstep while the clipper has its own version line. The last push to the repository was on 2026-09-21, and the repository is not archived. The release process is automated through Lerna with conventional commits (release:prod runs lerna version --conventional-commits), so changelog entries are generated from commit messages rather than written by hand.

Upgrade cost for a self-hoster is mostly the Node pin and the workspace rebuild. There is no documented migration path in the README for an existing self-hosted deployment moving between client versions, and no documented rollback. Version your own build artifacts before you replace them, because the repository will not tell you how to go back.

## Conclusion

Adopt standardnotes/app if you want to inspect or build the client yourself, or serve the web app from your own static host and point it at your own DEFAULT_SYNC_SERVER. Do not adopt it expecting the README to walk you through running a sync server; that path is linked out to the help site, not documented in the repository. Verify first that your Node version satisfies the engines range of >=12.19.0 <17.0.0, and confirm what your fork's AGPL-3.0 obligations are before you host a modified build.

## FAQ

### Is the Standard Notes app free?

The README states that Standard Notes offers fast, free, and encrypted cross-platform sync on unlimited devices, and the onboarding steps for registering an account and downloading clients do not mention payment. The .env.sample file does reference subscription-related endpoints (DASHBOARD_URL, PLANS_URL, PURCHASE_URL), so paid plans exist alongside the free tier.

### Is the Standard Notes app safe?

The README describes Standard Notes as end-to-end encrypted, with the claim that only you can read your notes, and it lists public source code plus the ability to self-host your own server as reasons to trust it. The client code is in this repository under AGPL-3.0, so you can read the encryption path yourself rather than take the claim on faith.

### What are people saying about the Standard Notes app?

The repository does not contain user commentary or reviews. The README links to the project's own community channels, a Discord server, a Twitter account and a forum at standardnotes.com/forum, which is where that kind of discussion happens.

### Why is the Notes app shutting down?

This question is not about Standard Notes. The repository shows no shutdown notice: it is not archived, its last push was on 2026-09-21, and it shipped mobile, desktop and clipper releases on 2026-09-17.

### How do I use the Standard Notes app?

The README's onboarding path is to launch app.standardnotes.com, click Register to create an account, then download the client for Mac, Windows, Linux, iOS or Android. Sync is end-to-end encrypted out of the box across those devices.

### What is the Standard Notes app?

The README describes it as an end-to-end encrypted note-taking app for capturing notes, files and life's work in one secure place, with encrypted cross-platform sync on unlimited devices. The standardnotes/app repository holds the TypeScript source for its clients.

## Sources

- [License: AGPL-3.0](https://github.com/standardnotes/app/blob/main/LICENSE)
- [Project website](https://standardnotes.com)
- [README](https://github.com/standardnotes/app/blob/main/README.md)
- [Releases](https://github.com/standardnotes/app/releases)
- [standardnotes/app on GitHub](https://github.com/standardnotes/app)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/standardnotes-app