Keep every client's source code sealed — and provably separate
An agency holds many clients' code at once. Sealrepo encrypts each codebase in its own Git repo and gives you access you can grant per project, audit, and revoke the day a contract ends — without re-keying anything.
Your team clones a dozen client repos onto a dozen laptops. Each one is plaintext at rest: a lost MacBook, an over-broad backup, a departing subcontractor with a lingering clone, or a CI token in the wrong log can expose code you contractually promised to protect.
Client MSAs increasingly require encryption-at-rest and access controls you can demonstrate. "It's in a private GitHub org" is not an answer when a client's security reviewer asks who could read the code and how access was removed.
How Sealrepo handles it
Each client's codebase is encrypted in its own vault
Source files are AES-256-GCM ciphertext on disk and in Git. A stolen laptop or a leaked clone exposes opaque blobs, not the client's product.
Per-project access, granted and revoked centrally
Add a developer to the one project they're staffed on. When they roll off, revoke — their vault re-seals on the next check. No re-keying every other repo.
An audit log you can show the client
Who was granted access, when, and when it was removed — a record that answers a security review instead of a shrug.
Recovery that survives staff turnover
A printed recovery code and optional cloud key escrow mean a client's vault doesn't die with one ex-employee's laptop.
The agency workflow
- 1.
sealrepo initSeal a client's repo on the lead dev's machine; it registers as a project on your dashboard. - 2.
sealrepo share --email [email protected]Grant the staffed developer time-boxed access to just that project. - 3.The team works normally — branch, merge, push. Encrypted blobs travel through Git like any other file.
- 4.
sealrepo lockdownContract ends: revoke access. Their vault re-seals; the audit log records it.
What Sealrepo does not do
- It is not DRM. While a developer is authorized and has unlocked, the files are normal files on their machine — they can read and copy them. Revocation stops future access, not copies already made.
- It does not encrypt your project-management metadata. Project names and member emails are stored server-side in plaintext to render the dashboard; only source code and keys are zero-knowledge.
- It is not a substitute for an NDA. Watermarking and audit logs make leaks attributable; contracts make them costly. Use both.
We spell this out because security tools that imply they do more than they can are the ones you should distrust. Read the full threat model.
Common questions
Can each client be fully isolated from the others?+
Yes. Every repo is its own vault with its own key and its own access list. A developer staffed on client A's project cannot decrypt client B's code — they were never granted it, and the key never existed on their machine.
What happens when a contractor or employee leaves?+
Revoke their access from the dashboard (or `sealrepo lockdown` for a project). On their next online check the vault re-seals and they can no longer unlock new versions. Anything they already decrypted while authorized is, like any tool, already on their disk — which is why revocation pairs with your NDA.
Does this slow the team's Git workflow down?+
No. Developers keep using ordinary Git — branch, merge, push, pull. Sealing and unsealing happen locally; a merge driver handles conflicts on encrypted content.
How are we billed for many client projects?+
The CLI is free for unlimited projects. The Team dashboard is per-seat — you pay for the people on your team, not per client repo.
Seal your first repo in 5 minutes
Free CLI, free account, no card. See how it compares to git-crypt & friends.
Get started