Hi, I would like to save data with git, encrypted (on some platform like bitbucket or github). Therefore the question:


I am looking for different hassle-free ways on:
How to set up an encrypted repository on bitbucket(/github)? Now, I am new to git, thus an instruction with all necessary steps or step by step would be much appreciated!


I found git-crypt, but on the site it is mentioned that it's intended for single file encryption. If one wanted to encrypt the whole repository they forward to git-remote-gcrypt.

In their README.rst they put it as simple as


git remote add cryptremote gcrypt::rsync://example.com:repo
git push cryptremote master
> gcrypt: Setting up new repository
> gcrypt: Remote ID is :id:7VigUnLVYVtZx8oir34R
> [ more lines .. ]
> To gcrypt::[...]
> * [new branch]      master -> master

or under


# notice that the target git repo must already exist and its
# `next` branch will be overwritten!
git remote add gitcrypt gcrypt::git@example.com:repo#next
git push gitcrypt master


I prefer full repository encryption, hence I tried git-remote-gcrypt with variations of the Quickstart and Example. So far I tried pushing an existing repository by following their instructions. Which yields this: (note: I have purposely changed the username to user)

-> with ssh as in the provided example

[...]/git_test$ git remote add origin gcrypt::git@bitbucket.org:user/test.git
[...]/git_test$ git push -u origin --allgcrypt: Development version -- Repository format MAY CHANGE
gcrypt: Repository not found: git@bitbucket.org:user/test.git
gcrypt: Setting up new repository
gcrypt: Remote ID is :id: ...
Zähle Objekte: 10, Fertig.
Komprimiere Objekte: 100% (6/6), Fertig.
Total 10 (delta 0), reused 0 (delta 0)
gcrypt: Encrypting to: --throw-keyids --default-recipient-self
gcrypt: Requesting manifest signature
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Fehler beim Versenden einiger Referenzen nach 'gcrypt::git@bitbucket.org:user/test.git'

or with https (which worked)

[...]/git_test$ git remote add gitcrypt gcrypt::https://user@bitbucket.org/user/test.git
[...]/git_test$ git push -u gitcrypt --allgcrypt: Development version -- Repository format MAY CHANGE
Password for 'https://user@bitbucket.org': 
gcrypt: Repository not found: https://user@bitbucket.org/user/test.git
gcrypt: Setting up new repository
Password for 'https://user@bitbucket.org': 
gcrypt: Remote ID is :id: ...
Zähle Objekte: 10, Fertig.
Komprimiere Objekte: 100% (6/6), Fertig.
Total 10 (delta 0), reused 0 (delta 0)
gcrypt: Encrypting to: --throw-keyids --default-recipient-self
gcrypt: Requesting manifest signature
Password for 'https://user@bitbucket.org': 
To gcrypt::https://user@bitbucket.org/user/test.git
 * [new branch]      master -> master
Branch master konfiguriert zum Folgen von Remote-Branch master von gitcrypt.

Nevertheless, I don't understand how to add users or even just pull my backup onto another machine (since my gpg key was generated locally) !? Feel free to just answer on usage of git-remote-gcrypt.

  • These might be related: - superuser.com/questions/676497/… The [filter][3]s link provided led me to believe that this is tricky usage of a git functionality that changes code(/content) upon push/pull. And the en-/de-cryption is done by the provided scripts. If that is the case, then I'd rather prefer a way that is easier to setup without the hassle of those scripts - programs like git-remote-gcrypt. Moreover this would reveal the contents of the repository, right? – gr4nt3d Jan 3 '17 at 14:27
  • - superuser.com/questions/900656/… Similar question specifically with bitbucket that has no answer. – gr4nt3d Jan 3 '17 at 14:27
  • 1
    Have a look at gist.github.com/shadowhand/873637 – Nifle Jan 3 '17 at 15:22
  • @Nifle seems to be the filter method as in my first comment, right? Does this encrypt the whole repo or just file-contents? – gr4nt3d Jan 3 '17 at 16:10
  • 1
    Have you looked at git-remote-gcrypt or Keybase ? – harrymc Nov 10 '17 at 7:43

A free and open-source tool is Keybase :

Git supports remote helpers. And we've made an open source one.

Keybase's remote helper performs all the crypto while letting git do its thing. This might sound impressive, but Keybase has not reimplemented git from scratch. We provide a remote helper, powered by the excellent go-git project, which we've begun contributing to.

We bring to the table: (1) crypto, (2) team + multi-device key management, (3) a safer concept of identity.

It is end-to-end encrypted. It's hosted, like, say, GitHub, but only you (and teammates) can decrypt any of it. To Keybase, all is but a garbled mess. To you, it's a regular checkout with no extra steps.

Even your repository names and branch names are encrypted, and thus unreadable by Keybase staff or infiltrators.

Teamwork is supported via Keybase Teams :

A Keybase team is a named group of people, with flexible membership. Let's say you work on a project called Treehouse. You could register treehouse on Keybase. This team name is universal; there can be only one Keybase team with a given name.

Teams get chats and channels. The chat looks a bit like Slack or Discord:

But Keybase teamwork is end-to-end encrypted, which means you don't have to worry about server hacks.


  • 5
    Nice tool there! However, it seems to be a closed eco-system. I could not find any hints showing how to work with non-Keybase-users. Is this possible? I guess forcing a whole team to use this tool or being dependent on it outweighs the benefits still. – gr4nt3d Nov 13 '17 at 15:00
  • 1
    I was referring to the usage; and am unsure how the git remote helpers actually work. Could one use a key (which is not pgp, but something new, right ?) and this helper but without the gui? – gr4nt3d Nov 14 '17 at 7:25
  • 1
    Keybase client is open source (for the moment), but not the server. They just sold themselves to Zoom, and there is utter silence on the fate of the project. Zoom has had a poor history with regard to privacy. – Diagon Jul 26 '20 at 2:15
  • 1
    Watch out: "On May 7, 2020, Keybase announced it had been acquired by Zoom[12], as part of Zoom's "plan to further strengthen the security of our video communications platform". Source: blog.zoom.us/… – Samuel Lampa Aug 18 '20 at 11:55
  • 1
    This doesn't work with any non-Keybase git hosting. It doesn't work with Github or Gitlab or such. Whenever Zoom decides to shutdown Keybase hosting, the one and only remote will be lost. – Acumenus Oct 17 '20 at 22:23

Step by step instructions, using git-remote-gcrypt and Bitbucket:


  • GnuPG (brew install gpg on macOS)
  • git-remote-gcrypt (brew install git-remote-gcrypt on macOS)


This guide will walk you through the process of creating and using a git repo called “gcrypt-sample” with Bitbucket, taking advantage of git-remote-crypt with a dedicated PGP keypair to provide end-to-end encryption.

Every push will be a force push!


Setting Up

  1. Set up your local and remote repositories:
    • Set up local repository with git init gcrypt-sample
    • On bitbucket.org, create a repository gcrpyt-sample
  2. Set up your ssh key if you haven’t already: ssh-keygen
  3. Add a gcrypt remote: git remote add cryptremote gcrypt::git@bitbucket.org:user/gcrypt-sample.git
  4. Generate your GPG keypair. Recommend this guide; for this sample, simply running gpg --gen-key will work.
  5. Configure gcrypt to accept the gpg key you just created:
    1. git config remote.cryptremote.gcrypt-participants <GPG key fingerprint>
    2. git config remote.cryptremote.gcrypt-signingkey <GPG key fingerprint>
  6. Edit your git repo:
    1. echo 'Hello, world!' > hello.txt
    2. git add hello.txt
    3. git commit
  7. git push -u cryptremote master
    • If you have multiple PGP keypairs, you’ll have to cycle through until you get the one you want—this is because you pull before pushing, every time; see the note below.

A note about pulling from the repo

Everytime you pull down (including when you push), you will have to cycle through your PGP keys until you get to the correct one. The reason for this is that the default for git-remote-gcrypt is to use a privacy guard which redacts the identity of the signing key. Consequently, when pulling from the repository, you have to check all of your available keys to see which one is the signing key. The signing key used can be published (and therefore anonymity revoked) by setting the remote.cryptremote.gcrypt-publish-participants property (to anything).

If you set an explicit and singular PGP key for the repo, doing that should be fine. However, doing so does have implications for shared repos (different commits can be tied undeniably to different users).

What’s Encrypted?

To my naked eye, pretty much everything.

What IS encrypted

  • Filenames (including paths)
  • File contents
  • Branches (I don’t know if the first branch pushed is logged under master, but all subsequent ones were)
  • Commit history: There is a single commit (“Initial commit”) and a single date (although dates of your pushes may be tracked by your remote separately, of course—BitBucket’s “Last updated” shows the accurate time. Of course, Bitbucket’s probably not paying attention to the commits themselves—it’s probably assuming you’re doing that.)

What is NOT encrypted

  • Repository name (though that’s obvious enough); just use a codename
  • The number or size of files (they are not distributed in any way); not sure what the implications are for different branches
  • 1
    git-remote-gcrypt seems like a bad choice because unless I misunderstood it, it can force push everything (merged into a single remote commit) each time. This makes it completely unscalable for pushes. Also, there is no support available, no maintained binary, and no place for users to discuss various issues. – Acumenus Oct 17 '20 at 21:46
  • Doesn't work for me, fail with an error and there's no support available. – GarouDan Apr 30 at 18:14

This can be accomplished in a decoupled way by using an actively developed user-space encrypted filesystem tool such as gocryptfs or cryptomator. The file paths are also encrypted.

gocryptfs usage

Personally I prefer gocryptfs over cryptomator because the former is a single binary and can also more easily be automated. That's even though cryptomator looks to be a more mature project.

gec is a bash utility which attempts to make it more convenient to use an encrypted gocryptfs filesystem in a git repo. At a minimum, note the -sharedstorage option which it uses with gocryptfs.

Cryptomator usage

  1. Create an encrypted vault in say ~/cryptomator/encrypted/myvault1. Optionally delete the useless file IMPORTANT.rtf from this directory.
  2. Run git init in the above directory containing the encrypted vault. Add one or more git remote URLs.
  3. Decrypt the vault into say ~/cryptomator/decrypted/myvault1. Add or change one or more files in the unlocked vault.
  4. Commit and push all changes in the git repo.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.