Revaulter

Encryption keys and signing keys don’t belong in environment variables or on disk. Revaulter keeps them in your passkey: scripts submit a request with the CLI, you approve it in your browser with a passkey, and the browser performs the crypto locally. Everything is End-to-End Encrypted (E2EE) between the CLI and your browser.

What you can use Revaulter for:

Screenshot of Revaulter, showing 3 requests pending approval: one for encrypting, one for signing, one for decrypting

Revaulter is fully open source and released under a permissive MIT license.

How it works#

A CLI or script submits an encrypt or decrypt request to Revaulter
The passkey holder gets notified (Discord, Slack, or a webhook)
They open the web app, authenticate with their passkey, and review the request
On approval, the browser derives the key from the passkey and performs the crypto operation locally
The CLI receives the encrypted result and decrypts it locally

Encryption keys are derived from the passkey in the browser (leveraging the PRF extension), they never leave the user’s device. The Revaulter server is just a relay: it temporarily stores only opaque, end-to-end encrypted envelopes.

Example of a notification sent by Revaulter to a Discord channel

Key features#

Passkey-derived keys — encryption keys are derived from WebAuthn passkeys (with PRF) directly in the browser; the server never has access to them
End-to-end encryption — all cryptographic operations happen in the user’s browser using WebCrypto, the server stores only opaque, encrypted envelopes
Self-hosted — runs on your infrastructure, you own your data and keys
Webhook notifications — get notified on Discord, Slack, or any webhook endpoint when a request is waiting
Lightweight — single binary, requires only a database (SQLite or PostgreSQL)
Strong cryptography — includes support for hybrid, quantum-resistant asymmetric cryptography

Encrypt, decrypt, and sign with passkeys

How it works#

Key features#