gopass

Last reviewed Sep 13, 2026 · 797 words

gopass is what you run when a team of 3 to 15 engineers already shares a git remote and each has a GPG or age key, and the question is how to share database passwords without a server. Every secret is a file encrypted to a list of recipient keys, the whole tree is a git repository, and adding a teammate means adding their key and re-encrypting. There is no web UI and no daemon to keep alive. It is pass with the sharp edges filed off and team features bolted on, and it is a poor fit for anyone who wants a browser extension that fills forms on every site.

What it changes from pass

The original pass is a shell script around gpg and git. gopass is a single static Go binary, 7,119 stars, MIT-licensed, that reads and writes the same store format, so an existing ~/.password-store opens unchanged. On top it adds multiple mounted stores (a personal store and a team store side by side, addressed as team/db/prod), an age backend for people who refuse to touch GPG, structured secrets with a password line plus key-value lines beneath, built-in TOTP with gopass otp, gopass audit for weak and reused passwords, and gopass sync, which pulls and pushes every mounted store in one command. Fuzzy search and tab completion are built in; gopass show -c team/db/prod copies the password to the clipboard and clears it after 45 seconds.

The recipient model is the feature and the trap

Each directory in a store can carry a .gpg-id file listing recipient key IDs; everything beneath is encrypted to all of them. gopass recipients add on a subtree gives a teammate access to team/db/ but not team/aws/, and gopass recipients remove followed by a re-encrypt revokes it going forward. Going forward is the trap: someone removed from the list still has the git history, which contains ciphertext they could decrypt at the time. Revocation therefore means rotating the actual credentials, not just editing .gpg-id. Teams that understand this run gopass happily for years; teams that expect removing a user to be sufficient belong on a server product with real access logs.

Day one for a team

gopass setup --remote [email protected]:ops/secrets.git --alias team
gopass recipients add 0xDEADBEEFCAFE1234
gopass insert team/db/prod
gopass sync

Host the remote on Gitea or Forgejo with a key per person and branch protection off, because gopass wants to push directly to the default branch. The git server never sees plaintext, which is the point: the repository can live on a shared forge because compromising the forge yields ciphertext and a list of who has access. Keep .gpg-id changes in the same commit as the re-encryption, and make gopass sync a habit before and after any edit, because the merge conflict from two people changing the same secret offline is a conflict in ciphertext, and git cannot help you resolve it.

Browser, editor and CI

The gopass-bridge extension talks to a small gopass-jsonapi native messaging host and fills logins from the store, matching on the URL you saved in the secret. It works, but it is a developer tool, not consumer autofill; expect to store URLs deliberately. In CI, a service account's key in the recipient list lets a pipeline run gopass show team/deploy/token without a secrets manager. That is the reasonable ceiling: past a handful of pipelines, or when secrets need TTLs and an audit trail, OpenBao is the tool built for the job.

When Vaultwarden is the safer pick

For a household, a company with non-engineers, or anyone who wants sharing to be a button rather than a key ceremony, Vaultwarden wins outright: organisations, collections, mobile apps, and removing a user actually removes their access from the moment you click. gopass's advantages are that there is no server to secure, no database to back up, and everything is inspectable with git log and gpg. Those matter to a specific kind of team; the password managers category exists for everyone else.

What I'd do

Engineering team, everyone already has a key, secrets are mostly API tokens and database passwords: gopass with the age backend for new members, a private repository on your own forge, recipient subtrees per environment, and a written policy that removing a person triggers rotation of everything they could read. Anyone else: Vaultwarden. And do not let one clone be the only copy of anything; the forge plus each person's checkout is the backup, so confirm that at least 2 clones outside the forge exist and are current.