Priced for the team
you actually have.

On cloud plans, in EU data centres — on Hetzner servers, a German provider, inside the EU. On a self-hosted deployment, wherever you put the server — we have no access to it, and it calls no external service.

Direct messages, group chats and channels are encrypted in your browser before they are sent, so we cannot read them. Files in CoreFiles are protected differently: each one has its own encryption key, sealed by a separate master key and stored apart from the file, so neither the file storage nor the database opens anything on its own. The service decrypts a file only to show or edit it for someone who has access — which is what editing documents online requires.

Yes. Every direct message is sealed separately for each device you are signed in on. A device you add later is the harder case: forward secrecy destroys the keys that opened older messages, so by default a new laptop starts from empty and nothing — including us — can recover what came before it.

So key recovery is on by default: your app keeps a sealed copy of each message as it reads it, under a key only your passphrase opens. Sign in on the new device, unlock, and your history is there. We default it on because the alternative loses messages quietly, every day, until somebody finds a switch — but it is a real trade, and here it is: someone who learns your passphrase can read your archived history. One switch in Settings turns it off and deletes every copy.

Direct messages, group chats, server channels and their attachments, plus meeting media on supported browsers. Attachments are sealed with the conversation key rather than the ratchet, so they are end-to-end encrypted but not forward secret. Not CoreFiles, calendar, tasks or forms. Files in CoreFiles are encrypted at rest with a separate key per file, and the text of calendar entries, tasks and form responses is encrypted at rest too. The service holds those keys so it can show and sync them, so none of this is end-to-end, and dates, times, attendees and the questions on a form are not encrypted.

For one-to-one messages, yes — the same construction. Direct messages now run over X3DH and the Double Ratchet: a separate session per device, a fresh key for every message, and a new chain on every reply. That gives forward secrecy, so a stolen key does not open yesterday's messages, and post-compromise security, so the next reply heals a session that was breached. It is our own implementation of the published specification on audited primitives, not Signal's library, and it has not been independently audited yet. It runs in the web and desktop apps.

Group chats and channels are not there yet. They stay on one shared group key handed to each member — end-to-end encrypted, but not forward secret. Sender keys are the next piece of work. And if the person you write to has published no device key, we fall back to the previous end-to-end scheme rather than send anything in the clear.

You submit a data-subject request and an administrator fulfils it — export as JSON, CSV or ZIP, or full erasure. A breach register and consent history sit behind the same panel.

There is no Google Analytics, no Sentry, no advertising pixel — no third-party code receives your data. We do keep our own product analytics, and those sit behind a consent banner.