Fast Note Sync for Obsidian: a self-hosted sync plugin that needs its own server

What Fast Note Sync solves, and for whom

Obsidian stores a vault as plain files on disk. That is the whole appeal, and it is also the problem: two devices editing the same vault have no shared state unless something moves the files. Fast Note Sync is a community plugin that watches a vault and pushes creation, update and deletion events to a remote service, then pulls the same events down on the other devices. The README describes it as a plugin for real-time sync across PC, mobile and web, with attachment support, note history, cloud backup and shareable links.

The intended user is someone who is willing to run a server. The README states plainly that a standalone server is required and links to haierkeys/fast-note-sync-service as the companion project. So the audience is narrower than the feature list suggests: self-hosters, people with a VPS or a home machine that is always on, and teams or individuals who want their notes on infrastructure they control. If you want sync that starts working after a plugin install and nothing else, this is the wrong shape of tool.

The client-server split behind the sync

The repository is the client half. The top-level layout holds src/, tests/, styles.css, manifest.json and an esbuild.config.mjs, which is the standard shape of an Obsidian community plugin built from TypeScript. The package.json describes the build as tsc -noEmit -skipLibCheck followed by node esbuild.config.mjs production, and the plugin's main entry is main.js. Nothing in the repository implements storage or a sync relay.

That lives in the server. One package.json script is telling: the proto target invokes pbjs and pbts against internal/proto/v1/sync.proto from the fast-note-sync-service repository to generate src/pb/v1/sync.js and src/pb/v1/sync.d.ts. The wire format is protobuf, generated from the server's schema, and the client carries the generated bindings. Practically, that means client and server versions are coupled through the protocol definition. The README already flags version floors in individual features, for example attachments requiring plugin v1.0+ with server v0.9+, and configuration sync requiring plugin v1.4+ with server v1.0+. Those notes are the project telling you that mismatched halves are a real failure mode, not a hypothetical one.

The tests directory names three suites in package.json: tests/websocket-auth-error.test.mjs, tests/file-mirror-restore.test.mjs and tests/vault-name-setting.test.mjs. The first is about authentication over a WebSocket, which is consistent with a persistent connection rather than polling. The second is about mirroring and restoring files. The third covers a vault name setting, which matters because the server has to distinguish one vault from another.

Installing the plugin and pointing it at a server

The README gives two paths. The first is the community plugin browser: open Obsidian Settings, go to Community Plugins, choose Browse, and search for Fast Note Sync. The README adds a caveat in parentheses, that if it is not listed in the store you should install manually.

The manual path is downloading three files from the GitHub releases page and placing them in the plugin folder inside the vault. The README names the files as main.js, styles.css and manifest.json, and the target path begins with .obsidian/pl, which is the truncated start of the per-plugin directory under .obsidian/plugins/. The release assets are what you place; you do not build the plugin yourself unless you are developing it.

pnpm run dev

That command is the repository's own dev script, which runs devts and devcss in parallel: devts runs the esbuild config and devcss watches src/styles.scss into styles.css. It is for contributors, not for installing the plugin into a vault.

After the files are in place, enable the plugin in Obsidian's Community Plugins list. Authorization is the next step, and the README describes two ways to do it: paste the remote service configuration, or use one-click import on the desktop app to complete authorization automatically. The README does not document the exact configuration keys, so read them from the plugin settings pane rather than from here.

There is also a Makefile with thin wrappers: make dev calls pnpm run dev, make build calls pnpm run build, and make translate calls pnpm run translate. None of this is needed to use the plugin.

Offline edits, deletions and the merge model

The hardest part of file sync is not moving bytes, it is deciding what wins when two devices disagree. The README claims two behaviours here. Offline note editing auto-merge is described as automatically merging modifications made on offline devices when they reconnect, explicitly to avoid the data loss that comes from keeping only the latest update. Offline deletion sync is described as propagating deletions of notes, attachments and configurations made while offline, either up to the server or down from it on the next connection.

Read that as a design commitment rather than a guarantee. Automatic merging of text is a category of problem where the honest answer is usually a conflict copy, and the README does not describe what the plugin produces when two devices edit the same paragraph in incompatible ways. It also does not document rollback of a sync operation, only note history with the ability to restore a note to a historical version. Note history is the safety net the project actually names, which is a reasonable place to put it, but it is per-note, not per-sync.

The attachment story has its own constraint. The README warns that large files may cause synchronization delays and asks you to manage attachment file sizes. There is also a cloud preview feature that lets attachments stay on the server and be previewed online instead of being pulled to the device, which saves local storage. Combined with the exclusion settings, the README suggests you can point certain attachment types at a third-party repository such as WebDav and keep them off the sync server entirely. That is a real escape hatch, and it also means attachment handling is a thing you configure rather than a thing that just works.

Where it is the wrong tool

The clearest limitation is structural: the plugin is useless without the companion service. There is no hosted offering described in the README, no account to create, and no fallback. If you cannot run a server, or cannot keep it reachable from your phone, the plugin has nothing to talk to. That rules out anyone who wants sync to be someone else's operational problem.

The second is encryption. End-to-end encryption appears in the README's roadmap as an unchecked box, alongside AI notes. It is a plan, not a feature. If your threat model includes the server operator, and you are the server operator, that is a different calculus, but the point stands: the README does not claim your notes are unreadable at rest on the server.

Third, configuration sync is explicitly labelled as being in a testing phase, with the README asking you to use it with caution. That is unusually direct and worth taking at face value. If your workflow depends on plugin settings matching across devices, treat that as experimental.

Fourth, the maintenance picture. The last push to the repository was on 2026-08-14, and the most recent release listed is 2.4.0 from 2026-07-20. The repository is not archived. That is a project with recent activity, but the release cadence clusters in July 2026, so check the releases page yourself before assuming a fix you need has shipped.

How it differs from Obsidian Sync and LiveSync

Obsidian Sync is the first-party paid service. You install nothing, run nothing, and the vendor holds the data. Fast Note Sync inverts every part of that: you install the plugin, you run the server, you hold the data, and you own the uptime. The trade is control and cost structure against operational work. If you are asking whether it is worth paying for Obsidian Sync, the honest answer here is that Fast Note Sync is not a cheaper version of the same thing, it is a different arrangement with a different failure surface.

Obsidian-livesync is the closer comparison, because it is also a community plugin that avoids the first-party service. The architectural difference is what sits in the middle. LiveSync's customization options let you choose a backend, typically a CouchDB database, and the plugin talks to that database directly. Fast Note Sync talks to its own purpose-built service over a protobuf protocol generated from sync.proto, with a WebSocket connection and authentication. The LiveSync approach leans on a general-purpose database that you may already know how to operate; the Fast Note Sync approach gives the project room to implement note history, shareable links, mirroring and a REST/MCP surface, at the cost of a component that only this project maintains.

If you already run CouchDB and want the smallest number of moving parts, LiveSync is the shorter path. If you want the plugin's own feature set, including attachment preview without local storage and the REST/MCP integration the package description mentions, the dedicated service is the reason those exist.

Licence and the cost of staying current

The repository is licensed Apache-2.0 according to the license badge and the repository metadata, though the package.json in the repository carries "license": "MIT". That disagreement is worth resolving before you redistribute anything, and it is a question for the project rather than for a reviewer. Apache-2.0 includes an explicit patent grant and requires notice preservation; MIT is shorter and does not. For someone installing the plugin into their own vault, neither changes much. For someone bundling it into a product, the difference matters, and you should read the LICENSE file at the repository root rather than the badge. This is not legal advice.

The upgrade cost is the more practical concern. Because the client ships generated protobuf bindings from the server's schema, the two halves move together, and the README's own version notes for attachments and configuration sync show that the project tracks minimum server versions per feature. The plugin has a version detection feature that reports the latest plugin and server versions, which is the intended way to notice you are behind. Budget for upgrading both sides, and read the release notes for the server before the plugin, since a newer plugin against an older server is the combination the version floors are there to prevent.

Editorial conclusion

Adopt it if you already run services for yourself and want note, attachment and configuration sync under your own control, including on Android and iOS. Skip it if you want sync that works without a server, or if you need end-to-end encryption today, since the README lists that as an unstarted roadmap item. Before committing, confirm two things: that you can install and keep running the companion Fast Note Sync Service, and that the plugin appears in Obsidian's community plugin browser for your platform, because the README says a store miss means manual installation from the release assets.

Frequently asked questions

Official sources

1. haierkeys/obsidian-fast-note-sync on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases