Encryption at rest
How Gitfence encrypts code at rest, what the recovery key opens, what locked means and what is not covered.
Short answer: Gitfence encrypts stored code with a key it does not keep; your credentials and recovery key hold wrapped copies.
Your code is encrypted at rest with a key we don't keep. The key is held by your people's and agents' Gitfence credentials and your recovery key; our database stores only locked copies of it. Your code is readable only in our server's memory while one of your people or agents is using Gitfence, and for up to ten minutes after. We do not back up your code.
What this does not cover: file names in your rules and audit log are stored as metadata. While your code is in use, a compromise of our running server could expose it. Gitfence reads your repositories through the GitHub App you installed, so our service can fetch your code from GitHub for as long as it is installed; uninstall it and that access ends. This is not zero-knowledge. For that, self-host.
The recovery key
- Save it at creation. After Create organization, Gitfence shows Save your recovery key. Choose Copy or Download as a text file, tick I saved my recovery key, then Continue.
- Make a new one later. Open Settings → Encryption. Choose Make a recovery key, or New recovery key and confirm Make a new recovery key?. The old key stops working at once.
- Keep it outside Gitfence. The app cannot show the key again or recover it.
The key opens the organization when no browser or token can.
What locked means
An organization is Open while a credential is in use and Locked after 10 idle minutes. While locked, a request for code fails with HTTP 423, and the page says This organization's code is locked. A credential that used it before can reopen it, as can an admin with Paste your recovery key and Open organization. Sign-in, audit, offboarding and timers keep working.
Lock now in Settings → Encryption locks immediately. It is not a suspension: the next request with an enrolled credential reopens the organization.
Notifications while the code is locked
Members get an email, and a Slack DM if Slack is connected, when someone requests their review, on GitHub or by mentioning @their-github-login in a pull request, a comment or a review (only if they can see that pull request). They also hear when someone comments on, reviews, approves, requests changes on, merges or closes their pull request, or when its CI fails.
While the code is locked, the message is built only from GitHub's event. It names the repository, the pull request number, what happened and who did it, plus a link. It has no title, no comment text, no file paths and no check names. A comment on a file the person cannot see sends nothing at all.
When the code is unlocked, the message can also include the pull request title and comment snippets, read through that person's own filter.
| Where | What is stored |
|---|---|
| Outside the vault (database) | Content-free metadata: prIndex (repository, pull request number, owner, agent, head commit id, members taking part), notifySeen dedupe keys, notifyQueue/notifyDigest/notifyInbox (repository, pull request number, kind, actor's GitHub login, GitHub comment/review ids, time), the githubPoll state (ETags, GitHub ids, pull request numbers, commit ids, update times, requested reviewers' logins), reviewAsks (repository, pull request number, member, who asked and how, time: the To review pins), and the lastWebhook time. |
| Inside the vault | Pull request snapshots with titles, bodies, comments and check output (collaboration.db), as before. |
Each person can choose Everything, Only review requests and my pull requests or None. They can choose a daily digest and turn Slack DMs on or off. Agents read notifications through the MCP tool notifications (with a cursor) or GET /api/me/notifications?since=<cursor>, never by email.
What is covered
Mirrors, filtered views, generated declarations, redactions, secret findings, pull request snapshots, test work trees and temporary files. Revoking a token or removing a person destroys that key wrap.
If everything is lost
If every browser, every token and the recovery key are gone, nobody can open the stored code, including us. The owner writes to support from their account's email and asks for a reset. We delete the encrypted copy and give the organization a new key; its code is mirrored from GitHub again. Rules, people, documents and the audit log are kept. Everyone re-clones (view history is gone), and the owner makes a new recovery key.
Gotchas
- Uninstalling the Gitfence GitHub App ends our ability to fetch code from GitHub.
- Backups never contain code.
- Self-hosted, the same encryption runs on your server, and the keys can be sealed with your own HashiCorp Vault key. See self-hosting.
Next: offboarding and exit packs.
Related guides
- Getting startedSet up Gitfence for your organization: create it, connect GitHub, add a repository, restrict folders and invite your first contractor.
- Offboarding and exit packsEnd a person's access, revoke tokens and agents, and download a signed exit pack with agreements, access history and exposure receipts.
- Self-hostingInstall Gitfence on your servers with docker compose: sizing, your GitHub App, the offline license, encryption and Vault keys, Fenced CI, backups, upgrades.