Server / deploy — overview
The server side is a single Go binary (obsidian-remote-server) that:
- Listens on a Unix socket (default
~/.obsidian-remote/server.sock). - Authenticates clients via a token file at
~/.obsidian-remote/token(32 random bytes, mode 0600, generated at startup). - Speaks JSON-RPC 2.0 (see API & protocol).
- Runs under your remote user — no root, no setuid, no system service required.
Three ways to run it
| Path | Effort | When |
|---|---|---|
| Plugin auto-deploy (default) | zero | You have shell access and want it to “just work” |
| Docker | low | Sandbox sshd + daemon for testing or hosting a vault for many users |
| systemd | medium | The daemon should outlive plugin reconnects, or pre-deploy across many hosts |
The plugin auto-deploys for 99% of single-user setups. Docker/systemd are for shared hosts, CI, or operators who want explicit lifecycle control.
Binary inventory (per release)
| File | Purpose |
|---|---|
obsidian-remote-server-linux-amd64 | x86-64 Linux daemon |
obsidian-remote-server-linux-arm64 | ARM64 Linux (RPi 4/5, Graviton) |
obsidian-remote-server-darwin-amd64 | macOS Intel |
obsidian-remote-server-darwin-arm64 | macOS Apple Silicon |
daemon-manifest.json | {filename: sha256} map for all binaries |
*.bundle | Cosign signature for each binary + manifest |
Compiled with the standard Go toolchain. No runtime deps beyond a Linux/macOS kernel + the system libc.
See Cosign verify to check a binary you downloaded.
What the daemon needs
- Read+write access to the configured vault root.
- Bind permission for the Unix socket (in
~/.obsidian-remote/by default). - CPU, memory: ~5 MB RSS idle; rises with watcher subscriptions and concurrent transfers. RPi Zero 2 W handles a moderate vault; RPi 4 effortless.
- Network: nothing. The daemon binds a local Unix socket. The plugin tunnels it through SSH; no port exposure required on the remote — see Firewall, ports & NAT.
Operating multiple users on one host
The defaults are home-relative, so multiple OS users on one host coexist out of the box — each spawns their own daemon under their own UID. See Multi-user hosting for the full discussion + the anti-pattern of sharing one OS user.
Next: Auto-deploy / Docker / systemd / Firewall / Multi-user.
For the binary’s full flag set (running it by hand, under systemd, or in a container), see Daemon CLI reference.