Source-at-rest encryption for Git
Seal your code. Protect what matters.
Your private repositories are hidden from the public, not from the platform. CodeSeal encrypts your most sensitive files before they ever leave your machine — so what is committed is unreadable to everyone but you.
- Local-only plaintext
- Git-native workflow
- Built in Rust
$ curl -fsSL https://codeseal.sh | sh
✓ sgit v1.0.0 → /usr/local/bin/sgit
$ sgit init --wizard
? Encryption mode › recipient
? CI mode › secrets
? Sensitive paths › src/secrets
✓ Wrote .sgit/manifest.yaml
✓ Managed .gitignore + hooks
✓ Encrypted 7 files → .sgit/store/
$ sgit add -s src/secrets/payment.env
✓ Adopted, encrypted, stanza written
$ sgit commit -m "protect payments"
[main 1a2b3c4] protect payments
$ sgit push origin main
✓ doctor pass · delegated to git push
"Private" does not mean unreadable.
A private repository hides your code from the public, but not from the platform itself. Anyone with privileged access to the storage backend can read every commit, branch and file in plaintext. For most teams that is fine. For payment engines, proprietary algorithms, security rules and trade secrets, it is not.
Hosting provider employees
Engineers and administrators at GitHub, GitLab or Bitbucket have backend access to private repository storage.
Storage breaches
If your hosting provider is compromised, every line of plaintext source in your private repositories is inside the blast radius.
Subpoenas and insider threats
Legal requests, a rogue employee or a misconfigured access control can expose source you assumed was private.
A thin, careful layer over Git.
CodeSeal does not replace Git or your hosting provider. It encrypts the files you nominate, manages the ignore rules and hooks for you, and stays out of the way the rest of the time.
Mark sensitive paths
Tell CodeSeal which files or folders hold your secrets. A directory is expanded into individual file entries in a versioned manifest, so what is protected is always explicit.
Encrypt locally
Plaintext never leaves your machine. Encrypted blobs go to
.sgit/store/, and that is what Git sees.Commit and push safely
sgit commitencrypts and checks before delegating to Git.sgit pushrepeats the safety checks before sending ciphertext and manifest.Decrypt where authorised
Teammates and CI runners holding a key decrypt on demand through
sgit run-secure.
my-app/
├── src/private/
│ └── payment_engine.py ← plaintext, ignored
├── .sgit/store/src/private/
│ └── payment_engine.py.sgit ← encrypted
├── .sgit/manifest.yaml ← path map
├── .gitignore ← managed
└── .gitattributes ← managed
Your host only ever sees the encrypted blob and the manifest. The real source never touches the wire.
Honest about what we protect.
CodeSeal protects source at rest in remote Git storage. Both halves of that sentence carry weight, so here is each one written out rather than implied.
What it protects against
Storage exposure at your Git host, whoever holds the keys to it. Accidental plaintext pushes, because the workflow checks before it sends. And any reader of the repository without a decryption key — to them the protected files are noise.
What it does not
A CI provider handed key material can read what it decrypts, and so can a deployment platform decrypting at build time. Nor does it help against a developer who already holds a valid key, a compromised machine, or plaintext already committed to history before you adopted it.
Two ways to hold the keys
Passphrase mode is one shared secret — simple, but removing a teammate means rotating it and re-encrypting everything. Recipient mode gives each person an age X25519 keypair and wraps a fresh per-file AES-256-GCM key to every authorised recipient. No shared secret exists, so access is individual, auditable and revocable one person at a time.
The ones people actually ask.
Does CodeSeal replace Git?
No. It wraps Git and uses normal Git storage for the encrypted blobs. Your hosting provider, your workflow and your tooling all stay exactly as they are.
Are the encrypted files committed?
Yes — everything under .sgit/store/ is committed and pushed. The plaintext originals stay local, ignored through a managed .gitignore block.
Can I add CodeSeal to a project that already exists?
Yes. sgit init --wizard walks through it interactively. One caveat worth reading twice: anything already pushed in plaintext stays in Git history until you rewrite it, which is what sgit history-rewrite is for.
Passphrase mode or recipient mode?
Passphrase mode is one shared secret for the team, and it is the simplest thing that works. Recipient mode gives every person their own keypair, so you can add, remove and rotate people without re-encrypting the repository. Use passphrase mode for solo work; move to recipient mode the moment more than one human needs access you might later want to withdraw.
Can my CI still build the project?
Yes, in four modes of decreasing runner trust — from handing the runner key material outright, to the Portal doing the build so the runner never sees plaintext at all. The CI guide lays out what each mode trusts with what.
Can the build provider see plaintext?
In three of the four modes, yes — the runner decrypts, so it can read what it decrypted. In portal-build mode your CI provider never sees plaintext, but the Portal worker does. CodeSeal protects source at rest; pick the mode matching who you are willing to trust with the build itself.