Short answer: Onetime Secret encrypts secrets on its server with a key derived from the server's own configuration, so the operator can technically decrypt a secret that hasn't been viewed yet. If you want a Onetime Secret alternative where the server only ever receives ciphertext, Evergist encrypts on your device and keeps the key in the link. Onetime Secret is the better pick when you need self-hosting, accounts, custom domains, or a choice of data region.
We make Evergist. Everything about Onetime Secret below comes from its own docs, repository, and pricing page, read on September 30, 2026.
What does Onetime Secret do well?
A lot. It has been running since 2011 according to its about page, and paid plans fund it.
- Open source and self-hostable. The repository is MIT licensed. The quick start is one Redis container and one app container. A fuller mode adds MFA, SSO, WebAuthn, and organizations.
- Accounts and teams. The pricing page lists unlimited members, role-based access control, single sign-on, and an audit trail in beta on the paid plans.
- Custom domains. The free Basic plan includes one custom domain such as
secrets.example.com. Paid plans add unlimited domains and your own branding. - Data regions. Five of them: Canada, the EU, New Zealand, the UK, and the US, each with its own domain and no shared data, per the regions docs.
- Email delivery and incoming secrets. It can email the link to the recipient, and a request link lets other people send secrets to you.
- A versioned REST API. v1, v2, and v3 are documented at api.onetimesecret.com, with an official Ruby client and community libraries in Go, Python, PowerShell, Bash, and others.
Evergist has none of the first five. If your company needs secrets on its own domain, under its own SSO, in a named region, use Onetime Secret or self-host it.
Is Onetime Secret end-to-end encrypted?
No. It encrypts at rest, on the server. Its docs say secrets "are securely encrypted on our servers".
The detail is in the project's own encryption audit, dated July 2, 2026:
- New secrets are encrypted with XChaCha20-Poly1305. AES-256-GCM remains readable for older data.
- "Master keys derive from
site.secret(config/ENV)". Keys live in the application's configuration and are not stored in the database.
That design protects against a stolen database. It doesn't hide the secret from the application, which receives your plaintext, encrypts it, and later decrypts it for the recipient. A Onetime Secret link looks like us.onetimesecret.com/secret/abcd1234. There is no key after a #, because the server holds the key material.
Can Onetime Secret read my secrets?
Technically yes, until the secret is viewed or expires. The server has the ciphertext and the secret that the keys derive from. Onetime Secret's about page says it doesn't store secrets after they've been viewed and doesn't want access to them, and nothing we read suggests otherwise. Server-side encryption still makes that a promise you take on trust.
The passphrase doesn't change that today. The about page FAQ says a passphrase is included in the encryption key. The July 2026 audit says the opposite. The passphrase is verified "as an access-control gate before decryption" against an argon2id hash, and "Passphrase is not a KDF input". Where the two disagree, we go with the audit, because it cites the code.
Self-hosting changes who the operator is. Run your own instance and the party that can decrypt is you.
How is Evergist different?
Three things.
It encrypts before upload. Your browser, the CLI, or the MCP server generates a 256-bit key, encrypts with AES-256-GCM, and sends only ciphertext. The key sits in the URL fragment, which isn't sent in HTTP requests. A password, if you set one, goes through PBKDF2 into the key itself, and 10 wrong attempts delete the note. The published encryption scheme comes with a Python script that decrypts a note without our code.
It has tools for terminals and agents. The CLI runs through npx with nothing to install first.
# One view, gone in an hour. Prints the link and a delete token.
printf '%s' "$DB_PASSWORD" | npx -y evergist create --views 1 --expires 1h
# Check a link without using its view
npx -y evergist status "https://evergist.com/g/<id>#<key>"
# Read it. This uses the view.
npx -y evergist read "https://evergist.com/g/<id>#<key>" > secret.txt
For agents there is a local MCP server with create_gist, read_gist, gist_status, and delete_gist.
claude mcp add evergist -- npx -y evergist mcp
It runs on the agent's machine over stdio, so encryption happens there. Onetime Secret's API works the other way around. The client sends the secret text and the server encrypts it, as the examples on its client libraries page show. Its client libraries page lists no MCP server for creating secrets. The MCP endpoint on its API portal is for querying the documentation.
It has no accounts. No sign-up, no API key, no cookies.
Setup for each client is in MCP server for sharing secrets and the agent guide.
Onetime Secret vs Evergist
| Onetime Secret | Evergist | |
|---|---|---|
| Where encryption happens | On the server | On your device |
| Cipher | XChaCha20-Poly1305, AES-256-GCM for older data | AES-256-GCM |
| Where the key lives | Derived from the server's site.secret |
URL fragment |
| Operator can decrypt an unread secret | Technically yes | No |
| Passphrase or password | Access check against an argon2id hash | Mixed into the key with PBKDF2, 10 wrong tries delete the note |
| Open source | Yes, MIT | Not yet |
| Self-hosting | Yes | No |
| Accounts | Optional. Teams, SSO, and RBAC on paid plans | None |
| Custom domains | Yes, one on the free plan | No |
| Data regions | CA, EU, NZ, UK, US | No choice |
| Longest expiry | 7 days anonymous, 14 days free account, 30 days paid | 30 days |
| View limit | 1 | 1 to 1,000, or none |
| Size | 100 KB anonymous, 1000 KB with an account | 512 KiB |
| Files | No, text only | No, text only |
| API | REST v1 to v3, takes plaintext | REST, takes ciphertext only |
| CLI | Official Ruby client, community libraries | npx -y evergist |
| MCP server for secrets | None listed in its docs | Local, over stdio |
| Price | Free, then 35 and 125 a month (euros on the EU page) | Free |
Neither is a vault or a secrets manager.
Which should I use?
Use Onetime Secret if you need to run the server yourself, put links on your own domain, manage a team with SSO, or pin data to a region.
Use Evergist if the requirement is that the service can't read the secret, or if a script or an AI agent is doing the sending. Know the limits first. The source isn't public yet, you trust the JavaScript our server sends unless you use the CLI, and an agent that reads a note does see the value.
For Yopass, PrivateBin, Enclosed, and the rest of the field, see Private note sharing compared.
Questions
Is there a free one-time secret tool without an account?
Onetime Secret works without an account, with a 7 day and 100 KB limit for anonymous use. Evergist has no accounts at all. Notes can be up to 512 KiB and last up to 30 days.
What is a Onetime Secret CLI alternative?
npx -y evergist create encrypts on your machine and prints a link. Onetime Secret's official client is a Ruby library that sends the secret text to its API with your account's API key. Share a secret from the command line has the full walkthrough.