No more customer passwords by email.
Request passwords, API keys and logins through a one-time, end-to-end encrypted link. The server never sees the plaintext.
Stop asking clients to send passwords by email.
Three ways Vault replaces the unsafe handoffs you do every week.
Request credentials securely
Generate a one-time request link. The other person encrypts the secret to a keypair that lives only in your browser. You receive ciphertext, never a password by email.
Share secrets with a one-time link
Encrypt in your browser, share a self-destructing link. The first read hard-deletes the secret server-side. No copy lingers in inboxes or chat history.
Verify the code and deployment
Every line of crypto is AGPL-3.0 on a public mirror. The status page exposes the deployed commit SHA and the SHA-256 of the browser bundle you can recompute yourself.
Request a secret without ever seeing it in plaintext
The request flow is what makes Vault different. Stop asking clients to email or Slack you their passwords.
Create the request
Your browser generates an X25519 keypair locally. The private key never leaves your device.
Share the request link
Send the link to the person who has the credentials. Email, chat, or even paper - the server never sees the key.
They submit the secret
Their browser encrypts the secret against your public key and uploads only ciphertext.
You collect it encrypted
Open your retrieval link. Your browser decrypts locally. Server-side plaintext exposure: zero.
What it looks like
Three steps. No account. No plaintext on the server.
Built for real credential handoffs
The same flow that protects a one-off password protects every recurring credential handoff in your day.
Agencies collecting client logins
Send one request link instead of chasing the client across three email threads. Nothing lands in your inbox in plaintext.
Developers sharing API keys
Hand over a Stripe key, GitHub PAT or AWS credential without leaving a copy in Slack or git history.
Support receiving sensitive data
Customers send 2FA backup codes, photo IDs or recovery seeds through a one-time link instead of a ticket.
Freelancers onboarding clients
Collect logins for legacy systems your client cannot wrap in SSO. Encrypted at their browser, decrypted at yours.
DevOps temporary credentials
Hand a colleague a short-lived production credential during an incident. The link expires, no cleanup forgotten.
Internal teams sharing secrets
Stop pasting passwords in shared docs. One-time link, hard-deleted after the first read, audit-friendly.
Built in the open, verifiable end to end
Six properties we hold ourselves to. Each one is reviewable in the public source.
Zero-knowledge by design
The server only ever stores ciphertext. The decryption key lives in the URL fragment and never reaches us.
Browser-side encryption
AES-GCM-256 and X25519 run via the browser-native WebCrypto API. No third-party crypto library, no plaintext on the wire.
URL fragment key separation
Browsers never send the part after # in HTTP requests. We put the key there on purpose, so the server is structurally unable to see it.
Open source, public mirror
Every line that runs your secret is AGPL-3.0-licensed and pushed to a public GitLab mirror. Read it, fork it, self-host it.
Deployed build verification
The status page exposes application commit, component commit, mirror commit and the SHA-256 of the bundle delivered to your browser.
Documented limitations
We list what this design does not protect against, including JavaScript-delivery risk and metadata leakage. No absolute-security claims.
Why not just use Password Pusher, PrivateBin or Bitwarden Send?
Based on public documentation and source code at the time of publication. Different tools optimise for different threat models. This comparison focuses on browser-based, one-time credential handoff.
| Feature | Erseni Vault | Password Pusher | PrivateBin | Bitwarden Send |
|---|---|---|---|---|
| Zero-knowledge (server never sees plaintext) | Yes | No | Yes | Yes |
| Request credentials from someone | Yes | No | No | No |
| Open source | Yes | Yes | Yes | Partial |
| Self-hostable | Yes | Yes | Yes | Yes |
| No account required | Yes | Yes | Yes | No |
Sources
Each claim is verifiable against the linked competitor source. If a value is out of date, open an issue on the public mirror and we will correct the table.
Password Pusher (GitHub) Server-side encryption with a server-held key; not zero-knowledge by design. AGPL-3.0 licensed, self-hostable, no account required.
PrivateBin (GitHub) In-browser AES-GCM encryption with key in the URL fragment, server stores ciphertext only. Zlib license, self-hostable, no account.
Bitwarden Send FAQ Server-side encrypted with an account-derived key; recipients use a one-time link. The Send feature requires a sender account. Server is AGPL-3.0; the official UI client and apps ship under a custom licence with proprietary components, hence the "partial" mark on open-source.
Verify our code
Trust is earned by being verifiable. The backend and the browser crypto are published under the AGPL-3.0 license.
Source: gitlab.erseni.net/open-source/secrets-component
Threat model: docs/architecture.md
Current build: status page lists the deployed commit SHA. Compare against the public mirror to verify.
Pricing
Free for personal use. No account. No tracking. No ads.
Business tier with audit logs, custom branding and SLA coming soon. Want early access? Email hello@erseni.com.