Sync your vault through a server that can't read it.

tuskd is local by construction: your vault is plain Markdown on your disk, and the daemon makes no outbound network calls until you say otherwise. OpenTusk Cloud is the opt-in "say otherwise": connect a vault to a cloud repo and the daemon keeps it synced — encrypting every change on-device, uploading only ciphertext, and pulling other machines' changes down to decrypt locally.

• Local stays local. Your working vault remains plaintext Markdown on your own disk — grep it, diff it, back it up, exactly as before.
• The server is ciphertext-blind. Encryption happens in tuskd before upload. The server never holds a key, a memory, or even a file name.
• Key custody is yours. A repo's master key is born on your first device and travels only inside encrypted wraps between your devices — or via a 24-word recovery phrase that's shown exactly once.

Connecting a vault creates (or joins) a cloud repo. From then on the daemon syncs automatically in the background (every 30 seconds by default); tuskd sync push and tuskd sync pull do the same by hand.

Keys

• Repo master key — 32 random bytes, generated on the first connecting device. It never leaves a device unencrypted.
• Recovery phrase — the master key encoded as 24 words, printed exactly once when the repo is created (and again only after a key rotation). It is both your disaster-recovery key and one of the two ways to join a new device.
• Device keys — each machine has its own ed25519 keypair. Every sync request is signed by a device key, and the server verifies signatures against the repo's device registry.
• Per-object keys — each synced object is encrypted (XChaCha20-Poly1305) under its own random key, kept in an encrypted key table wrapped by the master key. That makes key rotation cheap: revoking a device re-seals the small key table, not your whole vault.

Names

Objects are stored under keyed hashes of their paths, so the server can't learn your vault's structure from blob names. The mapping lives in the repo manifest — encrypted, like everything else.

"Private by construction" means the privacy doesn't depend on our promises — the server can't read what it never receives. Here is the complete inventory:

Even sign-in codes and session tokens are stored only as SHA-256 digests — there is nothing secret at rest on the server. The dashboard shows you this inventory live: everything the server knows about you, on one screen. Notice there are no notes in it.

From a vault that's already set up locally (see the tuskd quickstart), three commands connect it to the cloud. Sign-in is passwordless — a one-time code is emailed to you.

Install tuskd on the new machine, then enroll it into your repo. There are two ways in — a device approval ceremony (no secrets typed), or the recovery phrase (works even if no other machine is online).

Path A — device approval (recommended)

The fingerprint is derived from the new device's public key and rendered identically on both screens — compare the 16 characters before approving. That human check is what gates access: the server relays public keys and encrypted wraps, but it cannot approve anything by itself, and a device can never approve itself.

Once approved, the new machine pulls, decrypts locally, and materializes the vault — then keeps syncing automatically.

Path B — recovery phrase

Full access immediately, no approval needed — the phrase is the master key. This is also the disaster-recovery path: it works with zero other devices online.

tuskd sync status shows this machine's connection, fingerprint, and approval state; tuskd sync devices lists every device in the repo with statuses and fingerprints.

Lost a laptop, or retiring one? Revoke it from any other approved machine:

One command does the whole rotation: the revoked device is cut off from every future sync, a fresh master key is generated, the key table is re-sealed, and the remaining devices get new wraps. The old recovery phrase stops working; a new one is printed once.

cloud.opentusk.ai is the web view of your account — sign in with the same emailed code as the CLI. It shows your repos (storage used, device counts, activity), your devices (status, fingerprints, enrollment dates), your active sessions (with one-click revoke), and your plan usage.

The dashboard is exactly as blind as the server. It displays metadata the server legitimately holds — names you chose, sizes, timestamps, public-key fingerprints — and not one word of vault content, because the server has none to show. Treat it as the live audit of the inventory above.

Operations that touch key material stay in the CLI, where your keys actually live. For device approval, the dashboard acts as the second screen: it shows a pending device's fingerprint on a browser you already trust, alongside the exact tuskd sync approve command, pre-filled.

Accounts are passwordless: tuskd sync login emails you an 8-digit one-time code (valid 10 minutes), and a successful sign-in starts a 30-day session. The same code flow signs you into the dashboard. An account is only ever created on a successful verification — sending codes to an address creates nothing.

OpenTusk Cloud is in beta and free to use — no waitlist. The free plan includes one repo and 100 MB of encrypted storage; Pro is coming with more repos and more storage, and team repos follow general availability. Delete a repo you no longer need with tuskd sync delete-repo <repo-id> — the cloud copy is removed and the plan slot freed, while your local vault is untouched.

Everything lives under tuskd sync. The full tuskd CLI is documented in the tuskd reference.

What syncs — and what never does

Sync covers your vault's knowledge: memory records, skills, the review queue, and shared policy configuration. It deliberately excludes the machine-local secrets: agent private keys, the operator token, and the derived index (which every machine rebuilds locally). The boundary is the same one tuskd export draws.

Trust anchors

• Confidentiality rests on client-side encryption — not on server policy, promises, or jurisdiction. A complete compromise of the server yields ciphertext and the metadata listed above, nothing more.
• Access control rests on device signatures. Every sync call is signed by an approved device's key; approvals themselves must be signed by a different approved device. The server relays and verifies — it cannot grant.
• Joining rests on a human check: the 16-character fingerprint compared across two screens, or possession of the recovery phrase.
• Recovery rests on the phrase. We cannot reset it, resend it, or recover your data without it — that's not a support limitation, it's the design.

The server side is source-available (tusk-cloud); the client-side crypto ships in the open-source tuskd — the code that does the encrypting is the code you can read.