gopass: a pass-compatible password manager with GPG and git storage

The problem gopass solves: shared secrets without a server

Most password managers assume a vendor's servers hold the encrypted vault. gopass assumes the opposite. The README describes it as "a drop-in replacement for pass, the standard UNIX password manager," and states that by default credentials are encrypted with GPG and versioned in git. That combination is the whole product: the encryption key stays on your machine, and the store is a directory of files that a git remote can carry between people.

The target user is a team that is already comfortable with both tools. The README frames it as "Built for teams" from experience in distributed development teams, and lists three properties: the same experience on Linux, macOS, *BSD and Windows, no network connectivity required unless you want it, and an interface that is primarily the command line. CI/CD systems get named explicitly as a good fit.

That framing also defines who is excluded. If your team has no GPG keys, no git remote, and no appetite for either, gopass adds two dependencies before it stores a single password. The README is honest about the prerequisite: gopass "can operate without any dependencies but most users will use it with gpg and git," and an external editor is required for gopass edit.

How the store, the crypto backend and the git remote fit together

A gopass store is a directory of secret files plus a configuration file. The README states that gopass setup creates a new password store in $HOME/.local/share/gopass/stores/root and a configuration in $HOME/.config/gopass/config, using gpg encryption and git for versioned storage. Every write is an encrypted file committed to the local git repository, and gopass sync pushes and pulls those commits.

Both halves are swappable, and the README names the flags. Passing --crypto=age switches encryption to age instead of GPG. Passing --storage=fs opts out of versioned storage entirely. The go.mod file confirms the age path is real rather than aspirational: it requires filippo.io/age v1.3.2 and a ProtonMail/go-crypto fork. So the default is a choice, not a constraint.

The repository layout shows how much sits on top of that core. There are completion files for bash, zsh and fish at the top level, a gopass.1 man page, and separate directories named internal/ and pkg/. The Dockerfile is more revealing than the README: it builds gopass plus four companion binaries (gopass-jsonapi, gopass-hibp, gopass-summon-provider and git-credential-gopass) and installs git and gnupg into the runtime image. Those companions are not described in the README, so treat them as separate projects to evaluate on their own.

Installing gopass and creating your first secret

gopass ships through most system package managers. On macOS or Linux with Homebrew, the README gives a single command:

brew install gopass

Debian and Ubuntu users should read the warning in the README first: the gopass package in the official repositories is a different project. The supported route adds the project's own archive keyring and source list, then installs two packages.

curl https://packages.gopass.pw/repos/gopass/gopass-archive-keyring.gpg | sudo tee /usr/share/keyrings/gopass-archive-keyring.gpg >/dev/null
sudo apt update
sudo apt install gopass gopass-archive-keyring

Fedora, Arch, Alpine, Windows and the BSDs each have their own entry in the README, and Go users can run go install github.com/gopasspw/gopass@latest, though the README notes that latest is not a stable release and recommends released versions. Once the binary is on your PATH, initialize a store:

gopass setup

The setup wizard prints its banner, then asks you to pick a private key for encrypting secrets from a numbered list, and asks whether you want to add a git remote. Answering yes prompts for a remote such as [email protected]:john/passwords.git. If you already have a shared store, the README shows cloning it instead:

gopass clone [email protected]:john/passwords.git

Day-to-day use is short. gopass create makes a new secret, gopass ls lists everything, gopass show -c foo copies a password to the clipboard, and gopass rm foo deletes one. The README also notes that the bare form gopass [<key>] is a shortcut for gopass show [<key>], and that running gopass with no arguments enters a REPL.

Where gopass makes you pay for its design

The git-backed store is the source of most operational pain. Two people editing the same secret produce a merge conflict in an encrypted file, and the README does not document a conflict resolution workflow. There is no mention of rollback either. Recovery from a bad sync depends on your own git knowledge, not on a gopass command.

GPG key management is the second cost. The encryption boundary is the recipient list, and the README exposes gopass recipients as a command but does not explain how revocation propagates. Removing someone from a team means re-encrypting the store, and the README does not describe how to do that.

The third limitation is scope. gopass is a CLI tool. The README says it "can also integrate with your browser so you can largely avoid the command line," but that integration is not documented in the README itself; the browser bridge is one of the companion binaries in the Dockerfile. If your users need a polished desktop app or a web console on day one, gopass is the wrong starting point. The same applies to anyone who wants zero GPG exposure: choosing --crypto=age removes one dependency but the README does not describe how age recipient management compares to the GPG flow.

gopass versus pass, and when the drop-in claim holds

The obvious alternative is pass itself, the project gopass calls the standard UNIX password manager. Both store GPG-encrypted files in a git repository and both expose a command line. The difference in approach is scope. pass is a small shell script; gopass is a Go binary with subcommands, completion files for three shells, a man page, and a plugin surface visible in the Dockerfile.

That extra surface buys things pass does not have out of the box: a setup wizard, a REPL, mounts, a sync command, and the ability to swap the crypto backend to age or drop versioned storage with --storage=fs. It also means more code to audit and more commands to learn.

A second alternative is a hosted password manager. The trade is straightforward. Hosted tools give you a web interface and no key distribution problem; gopass gives you a store you can read, diff and back up with tools you already run, and it works on an air-gapped machine, which the README lists as a supported scenario. If offline operation or full data ownership is the requirement, the hosted option is disqualified before the comparison starts.

Licence, maintenance and what an upgrade costs

gopass is MIT licensed, and the repository carries an MIT License badge plus a LICENSE file. For most teams that means permissive use and redistribution with attribution. It says nothing about the git remote you point the store at, and nothing about the GPG keys you distribute; those are your own compliance questions, and the repository does not answer them.

Maintenance is visible rather than implied. The last push to master was on 2026-09-17, and the most recent release listed is v1.17.2 from 2026-09-10, preceded by v1.17.1 on 2026-09-09 and a release candidate the same morning. The repository is not archived. Releases are frequent enough that pinning a version matters for reproducible builds.

Upgrade cost is mostly the store format and the config file. The README does not document a migration path between crypto backends, so switching from gpg to age is not something to attempt casually on a store your team depends on. If you install from a distribution package, you inherit that distribution's release cadence rather than the project's, which is a reason to prefer the project's own apt repository on Debian and Ubuntu.

Editorial conclusion

Adopt gopass if your team already runs gpg and git and wants pass-compatible secret storage that works offline and in CI. Do not adopt it if nobody on the team is willing to own GPG key distribution, or if you expect a hosted web console. Before rolling it out, run gopass setup on one machine, confirm the store lands in $HOME/.local/share/gopass/stores/root, and check that gopass recipients lists exactly the keys you intend to share with.

Frequently asked questions

Official sources

1. gopasspw/gopass on GitHub
2. License: MIT
3. Project website
4. README
5. Releases