A Bitwarden-compatible password vault

Everlock now hosts your passwords. The new vault backend (backend-vault-http) speaks the Bitwarden protocol, so the official Bitwarden clients you already use — desktop, browser extensions, mobile, and the bw command-line client — connect to it directly, with no plugins or forks.

It is end-to-end encrypted and zero-knowledge: the server stores only client-encrypted ciphertext and a login verifier. Your master password and the plaintext of your items never reach the server.

What landed

• Account registration, login, and vault unlock against a self-hosted instance.
• Ciphers (logins, cards, identities, secure notes, SSH keys), folders, Sends, and file attachments — full create, update, and delete.
• Real-time sync over the notifications websocket: a change on one device shows up on the others without a manual refresh.
• Verified end-to-end against the official Bitwarden desktop app and the bw CLI — register, unlock, sync, save, and read items back in cleartext on the client.

Built the Everlock way

As with the OCI registry (over apimeister-registry) and the image library (over apimeister-photos), the protocol, crypto, and data model live in a standalone, clean-room engine — apimeister-vault, MIT/Apache licensed — and backend-vault-http is the thin Everlock adapter.

That adapter bridges the vault onto versioned storage, so every account, item, and folder write is a Git commit. The vault gets the same auditable, recoverable history as sites, mail, and calendars — and because the store is a plain Git repository, you can clone it and confirm for yourself that it holds only ciphertext.

Enabling it

Assign the backend a public vhost (Bitwarden clients require HTTPS, which frontend-http provisions via ACME), decide whether registration is invite-gated (the default) or open, and point a client at it:

[instances.default]
store = "everlock-vault"
vhosts = ["vault.example.com"]
open_signups = false

See the vault backend docs and the behavior and storage reference for the full picture.

What's next

• an Everlock-user-backed provisioning policy, tying account creation to the same identity and grant model as the rest of the system
• extending real-time push beyond ciphers to folders and Sends