Self-Hosted Password Management
with Git Sync

Every mainstream password manager requires you to trust a cloud provider with your most sensitive data. 1Password stores your vault on their servers. Bitwarden uses Microsoft Azure. LastPass has been breached twice. Even if the encryption is solid, the architecture means a third party holds your encrypted credentials, and you are trusting that their infrastructure, their employees, and their key management are flawless. What if you did not have to make that trade-off?

The Case for Self-Hosted

Self-hosted password management means your credentials never leave infrastructure you control. No cloud subscription. No third-party servers. No breach notification emails because a company you trusted got compromised. Your data lives on your machines, synced through protocols you choose, encrypted with keys that only exist on your devices.

The appeal is obvious for anyone who has thought carefully about threat models:

• No vendor dependency. If 1Password raises prices, changes terms, or shuts down, your data is locked in their ecosystem until you export it. Self-hosted means your data format and storage are under your control.
• No subscription. Cloud password managers charge $3-8 per month, forever. Self-hosted tools are typically free or one-time purchases. Over five years, the savings are $180-480.
• No third-party risk. The LastPass breach exposed encrypted vaults for 30 million users. The encryption may hold, but those vaults are now sitting on attackers' drives, being brute-forced indefinitely. Self-hosted means your vault is not in anyone else's database.
• Full audit trail. When you control the storage and sync, you know exactly where your data has been. No wondering whether a cloud provider's backup system retained a copy, or whether their CDN cached something it should not have.

Existing Self-Hosted Options

The self-hosted password management space is not empty. Several established tools exist, each with a different philosophy:

pass (The Standard Unix Password Manager)

pass is the original "passwords in Git" tool. It stores each credential as a GPG-encrypted file in a directory tree, with an optional Git repository for version control. It is command-line only, beautifully simple, and has been around since 2012. If you are comfortable with GPG and the terminal, pass is excellent. The limitation is that each credential is a separate file, so you cannot write contextual notes alongside secrets. You also need to manage GPG keys, which is its own operational burden.

KeePassXC + Syncthing

KeePassXC is a cross-platform password manager that stores credentials in a local .kdbx database file. Pair it with Syncthing (a peer-to-peer file sync tool) and you get self-hosted sync without any cloud involvement. The database is encrypted with AES-256, and Syncthing handles replication between your devices. The downside: .kdbx is a binary format. If two devices edit the database simultaneously, you get a sync conflict that requires manual resolution. There is no merge strategy for binary files.

Vaultwarden (Self-Hosted Bitwarden)

Vaultwarden is an unofficial Bitwarden-compatible server written in Rust. You run it on your own server (a Raspberry Pi, a VPS, a NAS), and use the official Bitwarden clients to connect to it. You get the full Bitwarden experience — browser extensions, mobile apps, auto-fill — without sending data to Bitwarden's cloud. The trade-off: you are now a server administrator. You need to maintain the server, keep it updated, manage TLS certificates, handle backups, and ensure uptime. If your server goes down, your password manager goes down.

The Problem with Traditional Self-Hosted Options

Every existing self-hosted option falls into one of two categories: simple but limited (pass), or powerful but operationally complex (Vaultwarden, KeePassXC + Syncthing).

pass requires GPG key management, which is notoriously painful. Key expiration, subkeys, key distribution, revocation — GPG's complexity is legendary. KeePassXC works well on a single device but struggles with multi-device sync because binary database files cannot be merged. Vaultwarden requires running a server, which means system administration, monitoring, and the constant question of what happens when the server is unreachable.

None of these tools let you write documentation alongside your credentials. pass stores one secret per file with minimal metadata. KeePassXC has a notes field, but it is a plain text box inside a database, not a markdown document. Vaultwarden inherits Bitwarden's notes field, which is similarly limited.

What if the sync mechanism was something you already know how to use? What if the storage format was something you could read without any special software? What if the credentials lived inside the documentation that gives them context?

Git as a Sync Engine

Git is the world's most widely used version control system. Developers already understand it. It handles merging, conflict resolution, branching, and history natively. It works over SSH, HTTPS, and local filesystems. It runs on every operating system. And critically, it was designed for plain text files — exactly what a markdown-based vault produces.

Using Git for password sync gives you properties that no other sync mechanism offers:

• Full version history. Every change to every credential is a commit. You can see who changed what, when, and revert to any previous state. If you accidentally delete a password, git log and git checkout bring it back.
• Meaningful diffs. Because the non-secret content is plain text, Git shows you exactly what changed in your notes. You can see that you added a new section to your deploy runbook, or updated a server address, or rotated three passwords (shown as changed enc:v1: blocks).
• Branch and merge. If you are testing new infrastructure and want to update credentials without affecting your main vault, create a branch. When you are done, merge it back. This is impossible with binary database formats.
• Multiple remotes. Push your vault to a private GitLab instance, a self-hosted Gitea server, or an encrypted USB drive. Push to multiple remotes for redundancy. Git's distributed nature means every clone is a full backup.
• No server required. Unlike Vaultwarden, Git sync does not require a running server. You can push to a bare repository on a NAS, a remote server, or even a shared folder. The "server" can be offline and sync will reconcile when it comes back.

How Claspt Does Self-Hosted Sync

Claspt initializes a Git repository in your vault directory by default. Every save auto-commits the change with a descriptive message. The repository is local — nothing leaves your machine unless you configure a remote.

To sync between devices, you add a Git remote and push. Claspt supports three sync approaches:

• Git remote (SSH or HTTPS). Push to any Git server — GitHub, GitLab, Gitea, a bare repo on your NAS, or a VPS. This is the most flexible option. Set up SSH keys once, and sync is automatic.
• WebDAV. If you have a WebDAV server (Nextcloud, Synology, or a simple WebDAV endpoint), Claspt can sync the vault directory over WebDAV. This is simpler than Git for non-technical users but loses version history and diff capabilities.
• SFTP. For users who want direct file transfer over SSH without Git, Claspt supports SFTP sync to any server you have SSH access to.

For most developers, the Git remote approach is the best choice. Here is how to set it up:

Setting It Up

The process takes about five minutes:

• Step 1: Create your vault. Open Claspt, create a new vault, and set your master passphrase. Claspt initializes a Git repository in the vault directory automatically.
• Step 2: Add your content. Create pages, add notes and credentials. Every save creates a Git commit in the background.
• Step 3: Add a Git remote. In Claspt's settings, add a remote URL. This can be a private GitHub or GitLab repository, a self-hosted Gitea instance, or a bare Git repo on a server you own. For example: git@your-server.com:vault.git
• Step 4: Push. Claspt pushes your vault to the remote. The files on the remote are plain markdown with encrypted secret blocks. Even if someone gains access to the remote, they cannot read your secrets without your passphrase.
• Step 5: Clone on another device. On your second machine, install Claspt and clone the vault from the remote. Enter your passphrase. All your notes are readable, all your secrets are decryptable.

From this point, changes sync bidirectionally. Edit on your laptop, push, pull on your desktop. Claspt handles auto-commit and can be configured to auto-push on save.

Security Considerations

The security model for a Git-synced vault is straightforward: the encrypted blocks are opaque to anyone without your master passphrase, and the non-secret content is readable. This means:

• The Git remote sees encrypted secrets. If someone compromises your Git server, they get your notes (which you wrote as plain text on purpose) and base64-encoded AES-256-GCM ciphertext for your secrets. Without your passphrase, the ciphertext is useless. The Argon2id key derivation makes brute-force impractical.
• Git history contains old encrypted values. When you rotate a credential, Git stores the old enc:v1: block in history. This is encrypted with the same key, so access to old commits does not help an attacker who lacks your passphrase. If you rotate your master passphrase, Claspt re-encrypts all blocks with the new derived key.
• Your passphrase is never stored. Not on disk, not in Git, not in a config file. It is entered at vault unlock, used to derive encryption keys in memory, and wiped when the vault locks. The Rust backend uses zeroize to ensure decrypted values do not persist in RAM.
• The threat model is explicit. Non-secret content (your notes, documentation structure, headings) is visible to anyone with access to the files. This is a deliberate trade-off that preserves search, diff, and portability. If you need every word encrypted, a full-vault encryption tool like Standard Notes is a better fit.

For a complete explanation of the cryptographic architecture, see our security documentation. For a full list of vault features, see features.

Self-hosted password management does not have to mean running a server, managing GPG keys, or fighting with binary database sync conflicts. A folder of markdown files, encrypted at the block level, synced with Git — that is all it takes. Your credentials, your infrastructure, your rules.