Skip to content

Sync and Devices

Se.Cherkasov edited this page Aug 23, 2026 · 1 revision

Sync and devices

English · Русский

Sync is optional and always your server: there is no vendor cloud. The server stores ciphertext and metadata; the master password and the encryption keys never reach it.

Running a server

The quickest path is the prebuilt image:

docker run -d --name skerry-sync -p 8080:8080 \
  -e SKERRY_JWT_SECRET="$(openssl rand -base64 48)" \
  -e SKERRY_ADMIN_TOKEN="$(openssl rand -hex 16)" \
  -v skerry-data:/data \
  secherkasov/skerry-sync:latest

It listens on http://localhost:8080, keeps SQLite in the volume, and serves a built-in offline web frontend: a public page at /, an account zone at /account, an operator console at /console. Configuration, PostgreSQL, TLS termination, backups, metrics and the admin CLI are documented in server/README.md; the protocol itself is in Sync protocol.

TLS: the server speaks plain HTTP and expects a reverse proxy (Caddy, nginx, Traefik) in front of it. Over http:// the payload is still E2E-encrypted and the password is never transmitted, but JWTs, metadata and the admin token are readable on the wire. LAN-only use over http:// is a deliberate, supported mode — the client warns about the URL anyway.

Connecting the first device

Settings → Sync → Set up sync: server URL, account id (an e-mail), master password. The client derives the keys locally and uploads an SRP verifier plus the wrapped data key — nothing that can decrypt anything.

Keep me connected reconnects automatically after a restart without asking for the password again.

Adding another device

Two ways:

  1. Sign in — same server, same account id, same master password.
  2. QR pairing — on a device that is already signed in, Settings → Sync → Link a device produces a QR and a one-shot code (sk1.…) valid for a few minutes. The new device scans or pastes it and chooses its own device password.

What syncs

Hosts and groups, keys and passwords, known hosts and trusted CAs, snippets, runbooks and run logs, tunnels, settings, terminal history, and the trash. Two deliberate exceptions:

  • File-backed keys — a key referenced by path is device-local; a path means nothing on another machine.
  • Nothing in plaintext, ever — every record leaves the device already encrypted.

Live updates and conflicts

A WebSocket carries a "changes available" signal that holds only the new cursor, never content; the client then pulls the delta. Conflicts resolve last-writer-wins by record version, with the device id as tiebreaker. Deletions travel as tombstones and are aged out on the server.

Devices

Settings → Sync lists linked devices with their platform and last sync, and revokes any of them. A revoked device can no longer pull; it may re-authenticate later unless the account is closed to it.

Web access

Settings → Sync → Web access sets a separate web password (8–256 characters) for the /account page in a browser. It is unrelated to any vault key: a browser session can read the metadata the server already holds — devices, teams, live sessions, record envelopes, the account's own log — and can revoke a device, but it can never decrypt a record. Clearing the password also signs out the open browser session.

If something goes wrong

Symptom Meaning
Plain http:// — not encrypted in transit the URL is not https://; fine on a trusted LAN, not otherwise
Re-enable fingerprint connecting to an account changed the vault key, so biometric unlock was turned off
Couldn't load devices. Try Sync now. the device list could not be fetched — the server is unreachable or the token expired

More in Troubleshooting.

Clone this wiki locally