# 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. URL: https://crunu.com/alternatives/git-crypt Language: en Updated: 2026-10-30 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 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. > **Note:** Crunu wrote this comparison. We checked every statement about git-crypt against its README, manual page and issue tracker on October 30, 2026, and the sources are listed with this page. If something is out of date, tell us at . ## 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. ## Side by side | | 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 | ## 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. *Figure: Diagram of who can decrypt git-crypt values, split into your side and the provider side. On your side, anyone with the file key can decrypt. The Git host and backups keep only encrypted files.* 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](https://crunu.com/features/offboarding) 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. *Figure: Example: Kiteline removes Tom Halvorsen in four steps. The exposure report shows which versions of which environments he received, when, and from which addresses, up to version 14 of payments-api / production. His access is removed and the keys of his six environments are rotated in the admin’s browser, with production in progress as five of six. The report lists 34 values to reissue at providers, by name only, and says that what’s been seen can’t be revoked. A card shows the server knows only what it served, never the values.* What neither tool can do is make someone forget a value they saw. Crunu's [limitations page](https://crunu.com/security/limitations) says this, and it is why the reissue checklist exists. ## Where git-crypt is stronger - **Transparent in Git.** After `git-crypt init` or `git-crypt unlock`, people use Git normally and never think about encryption again. Crunu asks people to sign in and run programs through `crunu 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 > **Note:** Crunu does not read git-crypt files directly. You decrypt the repository with git-crypt on a trusted computer and drag the plaintext files into Crunu. 1. [Create an account](https://crunu.com/signup) and save your Emergency Kit before anything else. 2. Create a project for the application and an environment for each set of files that should have its own readers, such as `staging` and `production`. 3. In a clone on a trusted computer, run `git-crypt unlock` so the protected files appear in plaintext in the working tree. 4. Drag those files into the matching environments. Crunu reads `KEY=VALUE` files, INI sections and flat YAML as fields, and keeps other text, such as a `.key` file, as a whole file. 5. Invite the team, enroll servers as machines and give pipelines service tokens with OIDC binding. Use `crunu run` or `crunu pull` where your code used to read the decrypted files. 6. 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. > **Warning:** A decrypted working tree holds plaintext secrets. Keep it out of synced folders, and delete any loose copies once the import is done. ## Other git-crypt alternatives If you want to keep secrets in Git but need to remove people, [SOPS](https://crunu.com/alternatives/sops) supports removing a key and rotating the data key with documented commands, and encrypts only values so diffs stay readable. [Ansible Vault](https://crunu.com/alternatives/ansible-vault) fits teams that deploy with Ansible, with a vault password instead of GPG keys. [dotenvx](https://crunu.com/alternatives/dotenvx) encrypts `.env` files with a keypair per file. [SOPS vs Ansible Vault](https://crunu.com/compare/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](https://crunu.com/alternatives/doppler) and [Infisical](https://crunu.com/alternatives/infisical) decrypt on their servers and add syncs to many platforms. The [who can decrypt guide](https://crunu.com/guides/who-can-decrypt-your-secrets) sorts all of these tools by who holds the keys. ## FAQ ### 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. ## Sources - [git-crypt README](https://github.com/AGWA/git-crypt) (accessed 2026-10-30) - [git-crypt manual page](https://github.com/AGWA/git-crypt/blob/master/man/git-crypt.xml) (accessed 2026-10-30) - [git-crypt issue 47: revoking access](https://github.com/AGWA/git-crypt/issues/47) (accessed 2026-10-30) - [git-crypt license (GNU GPL v3)](https://github.com/AGWA/git-crypt/blob/master/COPYING) (accessed 2026-10-30)