Teams
Shared access, unshared secrets
The usual way a team shares server access is a password in a document. This is the other way.
Shared vaults
A shared vault has its own key. Granting someone access seals that key to their public key, on your machine — so the server brokers who can open what without ever holding something that opens it.
The grant is signed, so a compromised client cannot forge one that appears to come from an admin. Removing someone from a team removes their grants in the same transaction; there is no window where a former colleague is out of the team and still holding a vault.
Sharing a session
Send a link and a colleague joins the terminal you are already in. They wait until you let them in, and they start read-only — typing is a separate, deliberate grant, per person.
The terminal stream travels over a direct connection between the two machines. Our service introduces you and then has nothing to do with it: it never sees a keystroke or a line of output. Withdrawing write access takes it back from everyone who already had it, immediately.
What the service can see
Which account owns a record, how big it is, and when it last changed. Not what is in it. Not a hostname, a username, a password or a key.
That is a property of the design rather than a promise: the encryption happens on your machine before anything is sent, and the key never leaves it.
Roles
- Owner
- Everything, including billing and deleting the team.
- Admin
- Invite and remove members, create and share vaults.
- Member
- Use the vaults they have been granted.
- Auditor
- Read access to session logs, no vault access.
Running it yourself
The sync service is a small Node application over Postgres. If your data cannot leave your own network, run it there — the desktop app takes a server address, and nothing about the encryption changes, because none of it ever depended on who was hosting.
- One process, one database, no queue and no object store
- The same API the hosted service runs
- Your clients point at it by URL