Secrets that self-destruct
Share passwords, tokens, and sensitive data with end-to-end encryption. Every secret is destroyed after reading — the server never sees your plaintext.
Built for security
Every decision prioritises privacy over convenience.
End-to-end encrypted
Encryption and decryption happen entirely in your browser using the Web Crypto API. The key never leaves your device.
Self-destructs after reading
Set a view limit of 1 or more. When the limit is reached, the ciphertext is wiped from Redis — gone forever.
Flexible expiry
From 1 minute to 7 days. If the secret isn't opened in time, it's automatically deleted.
Optional passphrase
Add an extra layer: require the recipient to enter a passphrase before the secret is decrypted.
API-first
Full REST API with API key authentication. Integrate secret sharing into your own tooling in minutes.
Open source & self-hostable
MIT-licensed. Audit every line of code, deploy on your own infrastructure, and trust no one.
Simple, transparent pricing
No hidden fees. Upgrade when you need more.
Free
For testing and light use.
- 10 secrets per month
- Max 24h TTL
- 1 view per secret
- Community support
Pro
For professionals and teams.
- 5,000 secrets/month
- Max 7-day TTL
- Up to 100 views per secret
- API access & dashboard
- Audit log
- Email support
Self-hosted
For teams that want full control and open-source deployment.
- Unlimited secrets
- Docker deployment
- Full infra control
- No cloud dependency
- Open source (MIT)
Frequently asked questions
Can't find an answer? Open an issue on GitHub.
Yes. Encryption happens in your browser before anything is sent to the server. The decryption key lives exclusively in the URL fragment (the part after #), which browsers never include in HTTP requests. Our server stores only ciphertext — mathematically unreadable without the key.
When the view limit is reached (default: 1 view), the ciphertext is immediately deleted from Redis. There's no soft-delete, no backup, no recovery. It's gone.
Yes. When creating a secret, you can require a passphrase. A PBKDF2-derived hash is stored server-side; the hash alone can't be reversed to retrieve the passphrase or the content.
Absolutely — that's a first-class use case. The API is a standalone Fastify service that only requires PostgreSQL and Redis. See the README for Docker instructions.
The link format is https://fadekey.app/s/#. Everything after the # is called the URL fragment. Browsers only use it locally — it's never included in the GET request, never in server logs, and never in Referer headers.
Yes. The public /api/items endpoint accepts any origin and can be called with curl, Node.js, Python, or anything that speaks HTTP. Pro accounts also get API key authentication and an audit log.