GitLocker

GitLocker protects encrypted repository content on the Git server. For the paths you encrypt, a host cannot read plaintext blobs, and a copied repository does not expose those files without the project key.

GitLocker does not protect plaintext already checked out into a working tree.

The product is Git repository encryption with pluggable key providers. Start by installing the free CLI and using the Personal Provider. GitBraints SaaS Server Provider is an optional upgrade for hosted keys and Grant. It is not a second encryption product.

Two-layer security

Source is exposed only when Git ciphertext and the project key leak together.

Two key providers

Personal Key Provider (free, default)

Keys stay on the local machine. GitBraints does not receive project keys on this path. This is the right start for individual developers and offline use. No GitBraints account is required.

“Keys are never uploaded” is true for the Personal Provider. It is not true for SaaS.

Server Key Provider (optional SaaS)

GitBraints can host usable project keys so you can manage many repositories and Grant fetch access. Collaborators keep using their own gitl login.

SaaS is not zero-knowledge. It holds usable keys. Its value is convenience and Grant, not replacing Git hosting ACL, and not a Cloud HSM or Team KMS.

The Server Key Provider does not accept password login. Sign in to GitBraints in the browser (including MFA), then either:

1. Device login: the CLI shows an activation code; approve it at /activate.
2. PKCE login: the CLI opens /cli/authorize; the loopback callback receives a one-time code, not an access token.

Manage repository keys at /home/gitlocker or /home/[team]/gitlocker. Exporting a plaintext key requires an email OTP. Team accounts exist for invite and Grant. They are not a second GitLocker login tenant.

How encryption works

GitLocker uses AES-256-GCM authenticated encryption. If ciphertext is truncated or tampered with, decryption fails closed. Filters must not emit plaintext, corrupt ciphertext, or partial output.

Daily user commands are gitl init, gitl encrypt <path>, gitl decrypt <path>, plus ordinary git add / git commit / git push. Git filters run for Git; they are not daily commands.

gitl encrypt applies going forward. It does not rewrite older Git history into ciphertext by default.

Collaboration and offboarding

Recommended flow:

1. A manager encrypts the repository and binds a key provider (Personal, or optional SaaS).
2. Invite collaborators on the Git host. If you use SaaS, issue a GitLocker Grant so they can fetch the project key.
3. When access should end, remove Git hosting access first (usually enough for private repositories).
4. Use SaaS key revoke / rotation only for public repos, widely cloneable ciphertext, or a confirmed key leak.

Session revoke (CLI logout) manages login state. It is not the same as emergency project-key revoke.

Product seats are billing and plan-limit containers. They are not a required encryption layer.

Security boundaries

1. After a successful checkout, the working tree is plaintext.
2. Git metadata (commit hashes, authors, timestamps, paths, approximate sizes) remains visible.
3. SaaS revoke stops future key fetches. It does not instantly wipe cached keys, and it does not rewrite Git history.
4. Rotation protects new work. Older commits may remain decryptable with a previous key version unless you re-encrypt separately.
5. GitLocker does not claim SOC 2, FIPS 140-2, HIPAA, or ISO 27001 certification.

Next steps

• Quick Start