git-crypt alternative that can revoke access: Crunu
Crunu and git-crypt compared: revoking access, what Git hosts still see, CI keys and audit records, checked against the git-crypt README and manual.
The difference in brief
git-crypt encrypts chosen files in a Git repository on commit and decrypts them on checkout for anyone holding the key, but by its own README it cannot revoke access once granted. Crunu keeps environments outside Git, with a key per environment, and rotates those keys when someone leaves.
git-crypt is the better pick when
- A mostly public repository holds a few private files, and Git should handle them transparently.
- The group with access never changes, and every member may read every encrypted file.
- You want an open-source Git extension with no service, account or vendor.
Crunu is the better pick when
- You need to take access away from a person or a machine, which git-crypt does not support.
- Pipelines and servers should fetch only their environments, without a shared repository key.
- You want a record of who received which values, and a list of what to reissue.
git-crypt and Crunu, property by property
The same 14 questions we ask of every tool, answered from git-crypt’s own pages and from what Crunu does today. Yes is not always better: read the note.
- Yes
- documented and available
- Partial
- with limits: on some plans, in preview or by hand
- No
- not offered
- n/a
- doesn’t apply, or isn’t documented publicly
| Property | git-crypt | Crunuour product | What it changes for you |
|---|---|---|---|
| Keys change when someone leaves | git-cryptNoIt does not support revoking access or rotating the key, per its README. github.com · | CrunuYesRemoving a member rotates the keys of every environment they could read and lists values to reissue. crunu.com/features/offboarding · | When people hold decryption keys, removing access is complete only once those keys are replaced. |
| Decrypted only on your devices | git-cryptYesFiles are decrypted on checkout, on machines that hold the key. github.com · | CrunuYesValues are encrypted and decrypted only in the browser and the crunu agent. crunu.com/security · | If values are decrypted only on devices you control, a breach of the vendor’s servers doesn’t expose them. |
| Server handles plaintext values | git-cryptNoNo server. The Git host stores encrypted contents, but file names and commit messages stay readable. github.com · | CrunuNoThe server holds no decryption key at any point. It still sees metadata such as names, emails and timestamps. crunu.com/security · | Whoever runs a server that handles plaintext, and anyone who breaks into it, could read what passes through. |
| Runs on your own infrastructure | git-cryptYesA Git extension with no hosted service. github.com · | CrunuPartialEnterprise plan only, under a signed agreement: your own server on Docker, Cloudflare Workers, Vercel or Google Cloud Run. crunu.com/self-hosting · | You decide where the data lives and who operates the service. Several tools, Crunu included, offer this only on an enterprise plan. |
| Source code published | git-cryptYesGNU GPL v3. github.com · | CrunuNoSource code is not published. crunu.com/security/threat-model · | Published code can be read and audited by anyone, and kept running if the vendor changes course. |
| CI signs in with OIDC | git-cryptn/aNo service to sign in to; CI needs the symmetric key or a GPG key. github.com · | CrunuYesService tokens bound by OIDC to repository, branch and environment on GitHub Actions, GitLab CI, Bitbucket or any issuer. crunu.com/features/ci-cd · | Pipelines get short-lived access tied to the repository, instead of a long-lived token stored in CI settings. |
| Separate key per environment | git-cryptPartialMultiple named keys per repository let you share different files with different people. github.com · | CrunuYesEach environment has its own key, sealed separately to each recipient's public key. crunu.com/features/access-control · | With a key per environment, access to development can’t turn into access to production. |
| Audit log | git-cryptNoKeeps no access record; it only encrypts files in Git. github.com · | CrunuYesHash-chained organization log with one-click verification and JSONL export, kept 365 days by default. crunu.com/features/audit-log · | A record of who changed or fetched what tells you what a person or machine could have seen. |
| Links for people without an account | git-cryptNoNo sharing feature; collaborators get the key through GPG or an exported key file. github.com · | CrunuYesLinks for people without an account; the key stays in the URL fragment. Expiry, view limit and password. crunu.com/features/access-links · | Contractors and one-off handovers get a value without it staying in chat history. |
| Free plan or free to use | git-cryptYesFree, open-source tool. github.com · | CrunuYesFree during early access. crunu.com/pricing · | A small team can start with real projects before anyone signs a contract. |
| Syncs values into other platforms | git-cryptNoEncrypts files in Git only; it does not push values to other platforms. github.com · | CrunuNoNo built-in sync to other platforms. CI can push values with crunu run as a recipe. crunu.com/integrations · | Pushing values into clouds and CI saves copying by hand, but the syncing service has to read them. |
| Dynamic secrets | git-cryptNoEncrypts stored files only; it does not generate credentials. github.com · | CrunuNoNot offered by design: generating credentials on demand needs a key on the server. crunu.com/security/limitations · | Credentials created on demand and revoked after a lease limit how long a leaked one works. |
| SSO and SCIM | git-cryptn/aNot applicable: there are no user accounts; access is by key. github.com · | CrunuNoNo SSO or SCIM. People sign in with a password, a Secret Key and an optional second factor. crunu.com/features/access-control · | Sign-in and provisioning from your identity provider make joining and leaving one step. |
| Kubernetes integration | git-cryptn/aNot documented publicly. github.com · | CrunuNoNo Kubernetes operator, Helm chart or CSI provider. crunu.com/integrations · | An operator or CSI driver delivers values into clusters without custom glue code. |
Comparison in detail
On this page
git-crypt and Crunu differ on one question: what happens after you give someone access. git-crypt encrypts the files you choose when they are committed and decrypts them when they are checked out, for anyone who holds the repository key. Its README states that it "does not support revoking access to an encrypted repository which was previously granted". Crunu was built around taking access away: each environment has its own key, and removing a person or a machine rotates every key they held.
For a small, stable group sharing a handful of files, git-crypt is hard to beat for convenience. Once people start joining and leaving, the missing revoke turns every departure into a full reissue of every secret in the repository.
Who each one fits
git-crypt fits repositories that are mostly public or shared, with a few private files such as *.key files or a file of API credentials. Once it is set up, you use Git as usual and encryption happens in the background. Developers without the key can still clone and commit; they just see the protected files as ciphertext. It is open source under the GNU GPL v3.
Crunu fits teams that need to know who can read which secrets today and to change that tomorrow. Secrets live in environments rather than in the repository. Each person, machine and pipeline gets only the environments it needs, and the day someone leaves is handled by one flow instead of a fresh key and a round of reissues.
Revoking access when someone leaves
The git-crypt README explains why there is no revoke. In GPG mode there is no command to complement add-gpg-user, and in symmetric mode the key cannot be rotated. Even a rotated key would not help with old commits: "a user having the previous key can still access previous repository history". Removing a person from your Git host stops them pulling new commits, but their copy of the key still decrypts every commit they already have, and any later commit they obtain under the same key.
In practice that leaves one safe answer: reissue every value in every encrypted file at its provider, whenever anyone with the key leaves. The more people have ever held the key, the more often that happens.
Crunu removes the person and rotates the keys in one step. The server stops serving them at once, every environment they could read gets a new key, and the member removal flow shows which versions they received, then lists the values to reissue at each provider. The reissue follows what the person actually received, instead of everything in the repository.
What neither tool can do is make someone forget a value they saw. Crunu's limitations page says this, and it is why the reissue checklist exists.
Where git-crypt is stronger
- Transparent in Git. After
git-crypt initorgit-crypt unlock, people use Git normally and never think about encryption again. Crunu asks people to sign in and run programs throughcrunu run. - Mixed public and private content. Contributors without the key can still clone, build the public parts and commit. Crunu keeps secrets out of the repository entirely, so this is not a problem it solves.
- No service at all. git-crypt is a Git extension with no server, no account and no vendor, and it works with any Git host and offline. Crunu always has a server, even when you host it.
- Open source. git-crypt is GNU GPL v3. Crunu's source code is not published.
Moving from git-crypt to Crunu
- Create an account and save your Emergency Kit before anything else.
- Create a project for the application and an environment for each set of files that should have its own readers, such as
stagingandproduction. - In a clone on a trusted computer, run
git-crypt unlockso the protected files appear in plaintext in the working tree. - Drag those files into the matching environments. Crunu reads
KEY=VALUEfiles, INI sections and flat YAML as fields, and keeps other text, such as a.keyfile, as a whole file. - Invite the team, enroll servers as machines and give pipelines service tokens with OIDC binding. Use
crunu runorcrunu pullwhere your code used to read the decrypted files. - Remove the files from the repository with
git rm, remove their patterns from.gitattributes, and commit.
The encrypted files stay in Git history, and git-crypt cannot take the key back from anyone who held it. Treat every value those files held as known to all past key holders, and reissue the ones that matter at their providers.
Other git-crypt alternatives
If you want to keep secrets in Git but need to remove people, SOPS supports removing a key and rotating the data key with documented commands, and encrypts only values so diffs stay readable. Ansible Vault fits teams that deploy with Ansible, with a vault password instead of GPG keys. dotenvx encrypts .env files with a keypair per file. SOPS vs Ansible Vault compares two file tools side by side.
If you would rather keep secrets out of the repository, hosted vaults such as Doppler and Infisical decrypt on their servers and add syncs to many platforms. The who can decrypt guide sorts all of these tools by who holds the keys.
More facts, row by row
Details beyond the 14 questions above, as this comparison states them.
| git-crypt | Crunu | |
|---|---|---|
| How it works | A Git filter encrypts chosen files on commit and decrypts them on checkout | Environments are fetched and decrypted by the browser or the crunu agent |
| Where values are decrypted | In the working tree of every clone that holds the key | Only in the browser and the agent, on devices that hold the environment key |
| What the host sees | Encrypted contents, but file names, commit messages and other metadata stay readable | Ciphertext, public keys and signed documents, plus metadata such as names, emails and timestamps |
| Giving access | Add a GPG user, which commits an encrypted key file to the repository, or hand over an exported symmetric key | An invitation, a fingerprint check with an admin, and a role on each environment |
| Different files for different people | Several named keys per repository, each shared with its own set of collaborators | A key per environment, plus a Specific files role that sees only chosen files |
| Revoking access | Not supported: no command removes a GPG user and the symmetric key cannot be rotated | Removal rotates the keys of every environment they could read and lists the values to reissue |
| CI pipelines | The job needs the symmetric key or a GPG private key | Service tokens limited to chosen environments, optionally bound by OIDC to a repository, branch and deployment environment |
| Record of access | None; it only encrypts files in Git | Hash-chained organization log, 365 days by default, with a record of which versions each person received |
| Sharing with someone outside | No sharing feature; collaborators get the key through GPG or an exported key file | Links for people without an account, with expiry, view limit and password |
| Change history | Git history; every change stores the whole encrypted file, since encrypted files do not compress | The last 100 versions of each environment, with rollback by a new version |
| Source code | Open source, GNU GPL v3 | Not published |
| Price | Free, open-source tool | Free during early access in the Crunu cloud; self-hosting on the Enterprise plan |
Sources
Every page this comparison relies on, and the day we last verified it.
- git-crypt README · checked October 30, 2026
- git-crypt manual page · checked October 30, 2026
- git-crypt issue 47: revoking access · checked October 30, 2026
- git-crypt license (GNU GPL v3) · checked October 30, 2026
Questions about Crunu and git-crypt
Something else? Write to support@crunu.com
Is Crunu an alternative to git-crypt?
Yes, for teams that use git-crypt to share environment files and credentials between people, servers and CI. Crunu keeps those secrets out of Git, in environments with their own keys and their own list of readers. If you only need a few private files in an otherwise public repository and the group never changes, git-crypt may be enough.
How do I move from git-crypt to Crunu?
Run git-crypt unlock in a clone on a trusted computer, drag the decrypted files into Crunu environments, then remove them from the repository and from .gitattributes. There is no importer. Reissue the values that matter, since past key holders can still decrypt the old commits.
Can git-crypt remove a user?
No. The git-crypt README says it does not support revoking access that was previously granted, in either GPG mode or symmetric key mode. Someone who held the key can still decrypt the repository history they already have.
Does git-crypt hide file names?
No. According to its README, git-crypt does not encrypt file names, commit messages, symlink targets, gitlinks or other metadata. It also does not hide when a file changes, its length, or whether two files are identical.
Can I use git-crypt and Crunu together?
Yes. You can keep git-crypt for files that must live in the repository and move application environments, cloud credentials and API keys into Crunu. Keep each secret in one place, so it is clear which tool to update when it changes.