Repository navigation
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.
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:latestIt 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.
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.
Two ways:
- Sign in — same server, same account id, same master password.
-
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.
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.
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.
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.
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.
| 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.
User guide
- Installation
- Getting started
- Hosts and connections
- Vault and credentials
- Terminal
- Files (SFTP)
- Port forwarding
- Remote desktops
- Snippets and runbooks
- Monitoring and guard
- AI assistant
- Sync and devices
- Teams and sharing
- Settings and shortcuts
- Android
- Troubleshooting
Development
- Architecture
- Building and running
- Connections and transports
- Terminal engine
- Vault and crypto
- Sync protocol
- Remote desktop stacks
- UI layer
- Testing and the gate
- Contributing and releases
Русский — оглавление