Fast Note Sync Service: A Self-Hosted Obsidian Sync Backend in Go

What Fast Note Sync Service actually is, and who it is for

This is a server, not a note editor. The README describes it as a "High-performance, low-latency note synchronization, online management, and remote REST API service platform", built with Golang, WebSocket and React. It does not read your vault by itself. The README states plainly that "Data provisioning requires integration with the client plugin", pointing at the separate Obsidian Fast Note Sync plugin repository.

The audience is therefore narrow and specific. You are an Obsidian user who wants your own server in the loop: your own machine, your own VPS, your own storage bucket. You get an admin panel for creating users, generating plugin configurations, and managing vaults and note content. You get a REST API for programmatic CRUD on notes, which the README frames around automation scripts and AI assistant integrations. You also get native MCP support, so the server can be attached to compatible AI clients such as Cherry Studio and Cursor, letting the model read and write your notes with changes distributed to all connected clients.

If you are not an Obsidian user, most of this is dead weight. The sync model, the .obsidian configuration sync, the PDF reading progress sync, and the attachment handling are all shaped around Obsidian's vault layout.

The sync path: WebSocket clients, a Go server, and a database underneath

The dependency list in go.mod tells you more about the architecture than the feature list does. The WebSocket layer is github.com/lxzan/gws, the HTTP layer is github.com/gin-gonic/gin, and storage is handled through gorm with three drivers present: github.com/glebarez/sqlite for SQLite, plus MySQL and PostgreSQL support. The README confirms all three are natively supported, positioned as covering "deployment needs from individuals to teams".

Several other dependencies reveal the shape of the feature set. github.com/blevesearch/bleve/v2 is an embedded full-text search engine, which is what sits behind note search. github.com/go-git/go-git/v5 is a pure-Go Git implementation, which is how the Git automation feature pushes changes to a remote repository without shelling out to a system git binary. github.com/robfig/cron/v3 drives the scheduled backup and mirror jobs. github.com/studio-b12/gowebdav handles WebDAV, while the AWS SDK v2 S3 packages and the Alibaba Cloud OSS SDK cover object storage. github.com/mark3labs/mcp-go is the MCP server implementation.

The data flow the README describes is: a client plugin connects over WebSocket, note and attachment changes are distributed to all online devices, and the server persists state in the configured database while optionally mirroring or backing up vault resources to S3, OSS, R2, WebDAV or a local filesystem. Attachments are chunked for upload and download, with a configurable chunk size. The README does not document the wire format beyond WebSocket, and the roadmap lists Protobuf transfer support as an unchecked item, so JSON over WebSocket is what exists now.

Installing Fast Note Sync Service and pairing the Obsidian plugin

The repository ships a Makefile and a docker/ directory. The Makefile defines a Docker Hub user and image name (haierkeys and fast-note-sync-service), which is the naming convention the published image follows. The build targets include build-linux-amd64, build-linux-arm64, build-macos-amd64, build-macos-arm64 and build-windows-amd64, so a source build produces a single static binary; the Makefile sets CGO_ENABLED=0 for compilation.

To build from source, clone the repository and run the default target, which the Makefile defines as test followed by build-all:

make

The README does not spell out the resulting binary path, so check the build directory the Makefile defines rather than assuming a location.

If you prefer containers, the docker/ directory is where the image definition lives, and the Makefile's push targets reference the haierkeys/fast-note-sync-service image name. The README does not publish a docker run command, so read the files in docker/ for the exposed port and volume layout before starting anything.

Configuration lives in the config/ directory. The README does not reproduce the config file contents, so treat config/ as the source of truth for database selection, storage backend credentials and chunk size. After the server is running, the workflow the README describes is: open the web admin panel, create a user, generate a plugin configuration, then paste that configuration into the Obsidian Fast Note Sync plugin on each device. The plugin is the client; without it the server has nothing to sync.

Where it breaks down: attachments in the trash, and a young authorization model

The trash bin is the clearest documented gap. The README says deleted notes go to the trash and can be restored, then adds that "Attachment restoration feature will be added sequentially in the future". So if you delete a note that references images and later restore it, the note comes back but the attachment restoration path is not there yet. For a vault with heavy image or PDF usage, that is a real operational hazard, not a cosmetic one.

The roadmap carries a second admission: "Isolate and optimize the existing authorization mechanism". That phrasing suggests the current authorization design is not considered final by the maintainer, and the README does not document how tokens are scoped, whether a user can be limited to a subset of vaults, or how revocation works. If you plan to expose this server beyond a trusted network, that silence matters more than any feature bullet.

The MCP integration deserves the same caution. The README states that an AI client can read and write your personal notes with changes synchronized across all clients. That is a large permission surface granted to a model, and the README does not describe a write-approval step or a dry-run mode. If you would not hand a script unrestricted write access to your vault, the MCP endpoint is the same grant with a friendlier interface.

How it differs from Nutstore Sync and peer-to-peer Obsidian sync

The obvious alternative for many users is a general file-sync service such as Nutstore Sync: point it at the vault folder and let it replicate files. The difference in approach is that a file-sync tool has no idea what a note is. It moves bytes. Fast Note Sync Service operates on notes as first-class objects, which is what makes note history, a trash bin, per-note sharing with password protection and access statistics, folder-level create/rename/move/delete sync, and .obsidian configuration sync possible at all. A file synchronizer cannot offer note revision history because it never parses the note.

Peer-to-peer Obsidian sync sits at the other extreme: no central server, devices talk to each other. That removes the hosting burden but also removes the things a server provides. There is no admin panel to create users, no REST API for scripts, no MCP endpoint, no scheduled ZIP backup to S3 or WebDAV, and no central place where note history lives. If your devices are rarely online at the same time, peer-to-peer sync has to reconcile later, and the README's offline strategy notes (automatic merging of offline edits, and offline deletions re-synced or deleted on reconnection) are features of this server plus its plugin, not of a peer-to-peer mesh.

The trade-off is honest: this project asks you to run a service. Nutstore Sync asks you to install a client. Peer-to-peer asks you to accept eventual reconciliation between devices that may never meet.

Licence, maintenance cadence and the cost of upgrading

The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It also requires that you preserve copyright and licence notices and state significant changes if you redistribute. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, have someone qualified read the terms.

The repository is not archived, and the last push was on 2026-08-14, which is recent enough that the project is being worked on. The release history shows 3.5.7 on 2026-07-15, 3.6.0 on 2026-07-20, and 3.6.1 on 2026-08-14, so the cadence is roughly a release every few weeks with occasional patch bumps. The README links a changelog at docs/CHANGELOG.en.md, which is where upgrade notes belong; read it before jumping versions, because the README does not document a downgrade path or a migration guarantee between releases.

Upgrade cost is dominated by your database choice. SQLite means you copy one file and you are done, which is why it suits a single user on a small VPS. MySQL or PostgreSQL means schema migrations run against a shared instance, and the README does not describe whether migrations are reversible. The Makefile injects version, git tag, build time and changelog into the binary via ldflags, so a rebuilt binary reports exactly which commit it came from, which helps when you are diffing behaviour after an upgrade.

Editorial conclusion

Adopt it if you want your Obsidian vaults on hardware you control and you accept running the server and the companion Obsidian plugin together, since the README states data provisioning requires that plugin. Do not adopt it if you want a zero-install sync product, or if you only need to move files between two machines, because the Git automation and one-way mirror sync features already cover that with far less moving parts. Before committing, verify three things: which database backend you will run (SQLite, MySQL or PostgreSQL), whether your storage target is one of S3, OSS, R2, WebDAV or a local filesystem, and whether the WebSocket Protobuf transfer format on the roadmap matters to your latency budget, because today the transport is JSON over WebSocket.

Frequently asked questions

Official sources

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