How the Dnote Self-Hosted Server Works for Syncing Across Devices

Updated

Dnote's self-hosted server is an optional component you run yourself to sync notes across multiple devices. It ships as a single binary backed by SQLite, so there is no separate database to install or configure, and you can deploy it with Docker or run it directly. If you only use Dnote on one machine, you don't need the server at all — the local notebook already works on its own.

What the server actually does

The server is a sync and access layer, not a replacement for the local notebook. Dnote's core design keeps everything in a local SQLite file, and the server exists to move that data between machines and expose it over HTTP.

Its two jobs are:

  • Multi-device sync — push notes from one device and pull them onto another so all your machines see the same content.
  • API access — a REST API lets you reach your notes from any HTTP client, which is what makes custom integrations possible.

Because the server also uses SQLite, it stays a single-binary deployment. There's no Postgres or MySQL setup step, and no dependency or package manager requirement for the client either.

How syncing fits with local storage

Dnote's local model is "one file contains everything" in SQLite format. That has a practical consequence for how you think about the server:

Aspect Local-only use With self-hosted server
Where notes live SQLite file on your machine SQLite file locally, synced through your server
Multiple devices Not synced Synced via the server
Database setup None None — server also uses SQLite
Programmatic access Via the local file and standard tools Via REST API over HTTP
Deployment Just the binary Docker or direct run

The local file remains the source of truth on each device; the server is what reconciles them. That also means you can back up the local file to any storage, query it with standard tools, or migrate it independently of the server.

Deploying it

The documented deployment paths are Docker or running the server directly. Both are single-binary approaches with SQLite underneath, so the choice is mostly about how you prefer to manage a long-running process rather than about capability.

A reasonable sequence:

  1. Decide whether you actually need sync. Single-device users can skip the server entirely.
  2. Choose Docker or a direct run based on your existing infrastructure.
  3. Start the server, then point your Dnote clients at it so they sync.
  4. Verify by creating a note on one device and confirming it appears on another.
  5. Optionally test the REST API with any HTTP client to confirm programmatic access works.

The expected result at step 4 is that a note written on device A shows up on device B after syncing — that's the whole point of running the server.

Common sticking points

  • Expecting the server to be required. It isn't. It's optional, and the local notebook works without it.
  • Assuming you need a database server. You don't. SQLite is built into the single-binary design.
  • Confusing sync with backup. The server syncs devices; it isn't described as a backup service. The SQLite file itself is what you back up to any storage.
  • Overlooking the API. If you want integrations or access from an HTTP client, the REST API is the mechanism — not the sync path itself.

Who should run it

Run the self-hosted server if you use Dnote on more than one device and want your notes to stay consistent across them, or if you want to reach your notes through the REST API. Skip it if you work on a single machine and are happy with the local SQLite file.

Dnote has been free and open source since 2017, so the server code is inspectable, forkable, and available to contribute to — which matters if you want to verify how your data is handled before trusting it with your notes.