What we protect — and what we don't
Sealrepo is built so that we never hold the keys to your code. This page is the honest contract: the things our architecture guarantees, and the things no encryption product (including ours) can promise. We believe stating the limits plainly is the real trust signal.
Zero-knowledge by design
Your source is encrypted on your machine with AES-256-GCM before it is ever written to the repository. The project key lives in your operating system's keychain and is wrapped end-to-end when shared with a teammate. Across the trust boundary between your machine and our servers, three things never cross: your plaintext key, your plaintext source, and your recovery phrase. Everything that does cross — encrypted blobs, wrapped key envelopes, signed access tokens — is useless without a key we never see.
What Sealrepo guarantees
- Your project key is generated on your device and never transmitted to or stored on our servers. We physically cannot decrypt your source.
- We store only encrypted blobs and an encrypted manifest. A full breach of our servers exposes no plaintext and no keys.
- Recovery secrets are encrypted on your device before upload. An attacker with our entire database cannot read them.
- Merges of encrypted files happen locally, in memory only — no plaintext base/ours/theirs/result ever touches durable disk during a merge.
- When you revoke a teammate, their access is dropped within ~30 seconds while online (or at their access lease's expiry while offline).
- Every recovery event is audit-logged on both sides and emails your verified address — recovery can never happen silently.
- Revocation always precedes recovery: a removed member cannot “recover” their way back in.
What Sealrepo does not protect against
These aren't bugs — they are the published boundary of what encryption can do. If a customer ever said "you never told me," we'd point here.
- We can't protect plaintext while a project is unlocked on your disk. Use full-disk encryption (FileVault / BitLocker / dm-crypt).
- We can't reach into your editor's memory, scrollback, or autosave files when a revocation lands — close open editors after a revoke.
- We can't stop someone with legitimate access from copying, screenshotting, or pasting what they can already see. This is true of any system that shows plaintext to a human.
- We can't protect a machine that is already compromised at the OS/root level. If your machine is owned, your keys are too.
- We can't recover a project if you lose your device, your recovery phrase, your account email, and your custodian's copy — that's by design (and why the setup wizard insists on backups).
- We can't hide metadata we need to render your dashboard: project names, member emails, roles, and timestamps live on our servers in plaintext.
The full threat model
This page is a summary. Our complete threat model enumerates seven adversaries — from a full server breach to a lost laptop to a malicious insider — and states, for each, what is and isn't protected, with each guarantee cited to a specific design invariant. It is published in the project repository alongside our build-verification recipe.