A password vault our own server can't read

Clusker keeps your projects, documents and tasks in one place, and it keeps passwords there too. The login for a client's hosting sits next to the project it belongs to, not in a separate app. That convenience raises an obvious question: if passwords live in the same product as everything else, who else can read them?

Our answer is part of how the vault is built, not a setting you have to find: nobody but you. Not our server, not someone with access to the database, not an AI agent connected to your account.

Encrypted before it leaves your device

The vault has its own master password. It is not your Clusker login password, and it is never stored anywhere, neither on the server nor in the browser. When you unlock the vault, all the key work happens on your device:

• Your master password goes through Argon2id, with 64 MiB of memory and three iterations. The result is a key that unwraps your personal X25519 private key, which is itself stored encrypted with AES-256-GCM.
• Every record gets its own random key, and its contents are encrypted with AES-256-GCM. The record key is wrapped in turn, and only keys decrypted on a device can unwrap it.
• The server receives ciphertext. The title of a record is inside that ciphertext too.

What stays readable on the server is deliberately dull: which project a record belongs to, what kind of record it is (a login, a card, a key or a note) and when it was created or changed. That is enough to group the list by project. It is not enough to learn anything.

No endpoint, nothing to leak

Clusker is API-first. The web app and AI agents connected over MCP go through the same JSON API. That is exactly what we want for tasks and documents, and exactly what makes a vault dangerous: if an endpoint returned passwords, sooner or later something would call it.

So there isn't one. The vault is left out of every path that could carry its contents elsewhere:

• Agents and MCP. There are no vault tools at all. It isn't that a token lacks permission. There is simply no method to grant permission to.
• The markdown mirror and git. Documents in Clusker are markdown files you can open in any editor. Vault records are never written to those files.
• Global search. Vault records never enter the search index. The server has nothing to index.
• Guest links. A page shared with a guest never carries vault records out.

That is the difference between a setting and a structure. A setting can be switched off by mistake, by a bug or by a well-meaning admin. An endpoint that doesn't exist can't be.

Locked by default

The vault is locked every time you open it. It locks itself after ten minutes without activity and when you close the tab. Passwords stay hidden until you press Show, and a copied password is cleared from the clipboard after 30 seconds. Every reveal, copy and edit goes into an access log that records who and when, never the secret itself. Decrypted data lives only in the memory of the open tab.

Touch ID and Face ID, with no server in the loop

The vault also opens with Touch ID or Face ID. It uses the WebAuthn prf extension: once your fingerprint or face is verified, the authenticator returns 32 bytes derived from a passkey secret that the page never sees and that is bound to our domain. From those bytes we derive a key that wraps the same private key a second time.

That second wrapping is stored in the browser on that device and nowhere else. Putting it on the server would have been convenient, and that is exactly why we didn't. Passkeys in iCloud Keychain sync between devices. If the wrapping lived on our server, someone who stole both your Clusker session and your Apple ID could open the vault without ever touching your computer. Kept on the device, that combination gets them nothing. The cost is small and we accepted it on purpose: if you clear site data, you turn quick unlock on again.

Biometrics add no server endpoint and replace nothing. The master password remains the root of everything.

The part that isn't a bug

If you forget your master password, the records it protects are gone. There is no recovery flow, and there won't be one. It follows directly from the first rule: a server that could restore your passwords is a server that could read them. Of everything here, this is the one thing worth knowing before you rely on the vault.

Why the vault came last

We built the vault after projects, documents, tasks and permissions had settled. It is the one part of Clusker where a mistake costs more than a delay, and encryption has to sit on top of an access model that has stopped moving, not the other way round. Our end-to-end checks run real X25519 keys against the real server routes, not stand-ins.

Next up is sharing a vault with your team, which is harder than it sounds when the server itself can never hand out a key. We'll write about it when it ships.