Crossnote: a local-first markdown notebook with in-browser git, now under new maintainership
📝 Local-first markdown notebook - notes live in your browser or local folders as plain markdown files, synced with in-browser git. No server, no account, works offline.
At a glance
- What is it?
- Crossnote stores notes as plain markdown in the browser or a local folder and syncs them with isomorphic-git, with no dedicated server. The original author has stopped maintaining it and shut down the backend; a new maintainer is rebuilding it from scratch, so what you adopt today is the legacy tag, not the rebuild.
- Who is it for?
- Adopt Crossnote only if you are willing to run the legacy-final tag or the archive/develop branch as-is and accept that the original backend is gone. If you need a maintained product with a release cadence, wait until the new maintainer publishes something past legacy-final, or pick a different tool.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Crossnote targets: notes that are files, not rows in someone's database
Most note apps put your writing in a database you cannot read without the app. Crossnote takes the opposite position. The README states that notes live in your browser, sync with any git repository directly, and stay plain markdown files, with no dedicated server in the middle. That is the whole pitch, and it is a narrow one: it is for people who already keep notes as .md files and want a browser UI on top of them, plus git as the transport. It is not for people who want a hosted service with a login, sharing links, and a support address. The repository topics list file-system-access-api, indexeddb, isomorphic-git, offline-first and privacy, which matches the claim: the storage layer is the browser, the sync layer is git, and the file format is markdown. If your notes are in Notion or Evernote, Crossnote does not migrate them for you and the README does not claim otherwise.
How the storage and sync layers fit together
Two storage paths appear in the material. The first is the browser itself, with IndexedDB named in the repository topics, which is what makes the app work offline. The second is the File System Access API, also in the topics list, which is how the app reaches a folder on your disk. The sync layer is isomorphic-git, a JavaScript implementation of git that runs in the browser, so a commit and a push happen from the page rather than from a terminal. The README does not describe the commit strategy, the merge behaviour, or what happens when two devices push to the same branch, and that silence matters. With a native git client, conflicts surface in your editor with a known workflow. Here the conflict handling is whatever the app implements, and the supplied material does not say what that is. Treat the git integration as the interesting part and the under-documented part at the same time.
Getting it running: build commands and the two things you must pick first
The repository is a Vite and React TypeScript project, based on the topics list and the primary language. The README does not include an install or build section, so the exact npm scripts cannot be quoted from the supplied material and I will not guess them. What the README does give you is a decision: the original author's final version is tag legacy-final, with the corresponding branch archive/develop, and the new maintainer is rebuilding the app from the ground up in a separate effort. So the first step is choosing which of those two trees you are building. After that, two environment constraints apply. You need a browser with the File System Access API if you want the local-folder path, which in practice means a Chromium-based browser, and you need a git remote that accepts an HTTP push initiated from a browser page. The README does not list supported browsers or hosts, so verify both against your own setup before you invest time in a notebook.
The maintainership gap is the real limitation, not the feature list
The README is blunt about status. The original author has moved on and the app's backend has been shut down. The release history supports that: v0.3.0 in March 2021, then nothing until legacy-final in July 2026, which is labelled as the final version from the original author. A five-year gap between releases is not a quiet period, it is an abandonment followed by a handover. The new maintainer says the plan is to rebuild from the ground up, which means the code you can install today and the code that will exist later are not the same codebase. Anyone evaluating Crossnote has to separate two questions: does the legacy app work for me now, and do I believe the rebuild will land. The README answers neither, and no release in the supplied material shows what the rebuild contains. That is the honest state of the project.
Where a browser-side git client will bite you
The failure modes follow from the architecture. A browser tab is not a daemon. If you close it mid-push, the material gives no indication of how the operation resumes or whether a partial state is possible. IndexedDB is per-browser and per-profile, so clearing site data removes the local copy, and the README does not describe an export path outside the git remote. If your remote is the only durable copy, then your notes are exactly as safe as your git host, which is a different risk profile from a local folder plus a remote. Large repositories are another boundary: cloning a big history into a browser tab is a different cost from cloning it in a terminal, and the supplied material contains no size guidance. None of this makes the design wrong. It makes it a design with edges that the README does not draw.
Obsidian and the difference between a plugin and a page
The obvious comparison for a markdown notebook with git sync is Obsidian with its Git plugin. Both keep plain markdown and both push to a remote. The difference is where the code runs. Obsidian is a desktop application with direct filesystem access and a plugin ecosystem, so git operations go through the system git binary or a bundled implementation with full process privileges. Crossnote runs inside the browser sandbox and reaches the disk through the File System Access API, with isomorphic-git doing the git work in JavaScript. That buys you nothing to install and a page you can open anywhere, and it costs you the privileges a desktop app has. If you want a mobile client, a plugin API, or background sync that survives closing the tab, a desktop app is the better fit. If you want a URL and no install, Crossnote is the one making that trade.
Licence, upgrades and the cost of following a rebuild
Crossnote is AGPL-3.0-or-later, per the LICENSE file, and the README carries two copyright lines: the 0xGG Team for 2020 and dongshunyao for 2026. If you fork it or host a modified version for others, the AGPL network clause is the part to read carefully; this is not legal advice, and the licence text is the authority. Upgrade cost is unusual here. There is no steady stream of patches to apply. There is a frozen legacy-final tag and a rebuild in progress, so the practical question is whether the rebuild will read notebooks created by the legacy app. The README does not say, and since notes are plain markdown plus whatever metadata the app stores in IndexedDB, the markdown will survive while the app state may not. If you adopt now, plan for a migration check between legacy and rebuilt versions rather than an in-place upgrade.
Editorial conclusion
Adopt Crossnote only if you are willing to run the legacy-final tag or the archive/develop branch as-is and accept that the original backend is gone. If you need a maintained product with a release cadence, wait until the new maintainer publishes something past legacy-final, or pick a different tool. Before installing anything, check whether your browser is Chromium-based (File System Access API), confirm your git host accepts a browser-side push, and read the AGPL-3.0 terms in LICENSE plus the two copyright lines, since the licence and the ownership split are the two things a fork has to get right.
Community notes