Server deployment

The server holds the replica, the branches, and the engine processes. The CLI talks to it over an authenticated HTTP API.

Run the server

# generate an admin token and start the server
$ export SNAPSHOTDB_TOKEN=$(openssl rand -hex 32)
$ snapshotdb serve --bind 127.0.0.1:8080 --db-bind 0.0.0.0 --public-host branches.internal

• --bind — where the control API listens.
• --db-bind — interface used for branch database connections. Use a private interface and restrict access in your firewall.
• --public-host — the hostname branch connection URLs are handed out with (reachable by whoever will use the branches).
• SNAPSHOTDB_HOME — where the server stores databases (default ~/.snapshotdb). Put it on a reflink-capable volume.
• SNAPSHOTDB_TOKEN — the single admin token every request must present as Authorization: Bearer.

Point clients at it

export SNAPSHOTDB_SERVER=https://snapshotdb.example.com
export SNAPSHOTDB_TOKEN='…'

Every command becomes an authenticated server job. The CLI submits it, waits, and prints the result; --detach returns a job id immediately and snapshotdb job <id> reconnects. A dropped client connection does not cancel the work — a long initial copy keeps running server-side, and status monitors it.

Connect the browser console

Serve the API over HTTPS, then set the exact console origins on the server before starting it:

export SNAPSHOTDB_CONSOLE_ORIGINS=https://snapshotdb.io,https://www.snapshotdb.io

In Console → Connection, enter your HTTPS API address and server token. Cross-origin access is disabled unless explicitly allowed. For local development, allow http://localhost:3000.

Reboots

Restart snapshotdb serve to restore branch proxies and restart synced roots. Use the systemd deployment unit to start it automatically after reboot.