Joplin: Markdown on the device, optional sync, and a published canary key

Offline first means the device holds the notes, not the server

The README defines offline first in plain terms: you always have all your data on your phone or computer, and your notes stay accessible whether or not you have an internet connection. That single design choice is what separates this from a web notes service, and it cascades into everything else. Sync is a separate decision you make later, not a precondition for taking notes. The targets named are Nextcloud, Dropbox, OneDrive and Joplin Cloud, and the transport uses end-to-end encryption with a dedicated page describing it. Joplin Cloud is linked to the plans page, so it is the paid option in that list; Nextcloud is the self-hosted one. The practical consequence is a two-step decision: the application is free and useful on its own, and the sync choice is where money or server administration enters. Full text search is described as available on all platforms, so the local database is not a crippled fallback.

Notes are Markdown, and the import path converts Evernote content

The storage format is named in the first paragraph: notes are in Markdown format, they are organised into notebooks, and they can be searched, copied, tagged and modified either from the applications or from your own text editor. That last clause is the interesting one, because it means the editor is not a boundary. The import story is spelled out for a specific audience: notes exported from Evernote can be imported with their formatted content converted to Markdown, their resources such as images and attachments, and their metadata including geolocation, updated time and created time. Plain Markdown files can be imported too. The consequence for anyone deciding: the risk in this application is not format lock-in, since the files on disk are readable text, it is synchronisation conflict, and a second editor on the same notebook is a genuine source of that. The extension points follow from the same premise, with plugins and themes supported, and you can write your own.

No install command here, and the Web Clipper is a browser extension

This repository does not contain installation instructions in the sense a reader can copy. The README points at joplinapp.org and at the full documentation hosted there, and it describes the platforms the application is available for: Windows, Linux, macOS, Android and iOS. The one browser-side piece is documented concretely, a Web Clipper for saving web pages and screenshots from your browser, with links to a Firefox add-on and a Chrome extension. For a first use, that is the shape of the workflow: install the application for your platform, install the clipper if you want to capture pages, then decide about sync. At the repository root there is a file named Joplin_install_and_update.sh, which tells you a shell route exists for at least one platform, but the README does not describe what it does or which platforms it covers, and it is not documented anywhere in the text. Do not assume it is the recommended path.

The dev branch builds need Node 22.19 and exactly yarn 4.14.1

The default branch is dev, and the released versions are v3.7.21, v3.7.18 and v3.7.16, all from September 2026, with the last push to dev on 2026-09-29. A contributor therefore builds from the same branch the releases come from rather than from a stable branch. The manifest is a private root workspace covering packages/*, with lerna.json alongside it, and it pins the toolchain twice: node at 22.19 or newer, and yarn at exactly 4.14.1 with no caret. The exact pin is the practical constraint, since a different yarn release is not a supported configuration. Around that sit the release and quality machinery: fastlane/ for the store builds, gulpfile.js, jest.config.base.js, eslint.config.js, lint-staged.config.js, renovate.json5, crowdin.yml for translations, cspell.json for spelling, and a .husky/ directory for git hooks.

buildParallel and buildSequential are the same command

Two scripts in the root manifest carry different names and identical bodies. buildParallel is a yarn workspaces foreach invocation with --worktree, --verbose, --interlaced, --parallel, --jobs 2 and --topological-dev, followed by yarn tsc. buildSequential is that same string. Nothing in the command changes the job ordering, because --topological-dev is what decides that a workspace builds after its dependencies, and the job count is what limits concurrency. So the meaningful knob is the job count, not the script name, and anyone reaching for the sequential variant to debug a build order problem will get the same interleaved run. The same file also carries circularDependencyCheck, which runs madge with --warning and --circular over the repository, plus checkGeneratedFiles, checkLibPaths and checkIgnoredFiles, which exist because parts of this tree are generated and the checks stop you from editing them by hand.

Four Dockerfiles, and transcription is a separate service with a GPU variant

The container story is bigger than a single server image. There is a Dockerfile.server and a Dockerfile.transcribe, and the transcribe one has a third variant, Dockerfile.transcribe.gpu, which exists because transcription is the part that benefits from hardware acceleration. Four compose files match that shape: docker-compose.server.yml for the service itself, docker-compose.transcribe.yml for transcription, and docker-compose.server-dev.yml and docker-compose.db-dev.yml for development. Configuration arrives through two sample files, .env-sample and .env-transcribe-sample, so the two services have separate settings surfaces. The consequence is that the default mental model of Joplin, a notes app you install locally, is not the whole deployment: there is a server mode, a separate transcription service, and a development database path. Anyone evaluating Joplin for a team should start from the server compose file rather than assuming the desktop app scales to a shared instance.

A canary key and a licence field that says NOASSERTION

Two things in this repository reward a close read. The first is the Warrant Canary signing key, published in the README with the fingerprint F820 F830 6DD0 05A1 02D1 8CD5 946A E9FA 5915 EF53 and a public key file under Assets/keys. A canary token is a mechanism for detecting that a build was produced under a legal demand to disclose, and publishing the key publicly is what lets anyone check a binary for it. The donation section explains the context: development costs include digital certificates to sign the applications, app store fees and hosting, which is a project whose binaries are signed and shipped through stores. The second is the licence. The README calls Joplin free and open source, a LICENSE file sits at the root, and the repository metadata reports the licence as NOASSERTION, so a dependency scanner or a corporate policy tool reading the field learns nothing. Read the file.

Editorial conclusion

Choose Joplin when you want a notes application that keeps working with no network, stores plain Markdown you can edit in any editor, and offers encrypted sync without handing your notes to a note vendor. Choose something else if you need collaborative editing on shared documents, since nothing in this repository describes multi-user editing. Verify four things before you commit. Which sync target you use, because Joplin Cloud is a paid plan while Nextcloud is one you run yourself. That you can live with a development branch, since dev is the default branch and the v3.7.x releases are cut from it. What the LICENSE file says, because the repository metadata reports the licence as NOASSERTION and a scanner cannot tell you the terms from the field. And whether your threat model includes a legal demand for data, since the project publishes a Warrant Canary signing key and its fingerprint in the README, which is a signal worth understanding before you install.

Frequently asked questions

Official sources

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