Secrets that vanish
after they are read
Send a password or an API key as a one-time encrypted link. It destroys itself on read, so nothing is left sitting in an inbox or a chat log afterwards.
On every plan, free included. No card required.
Someone sent you a secret
This will be shown once and then permanently deleted. Make sure you are ready to save the contents.
Simple. Secure. Gone.
Three steps from typing the secret to it no longer existing.
-
01
Write your secret
Paste the password, key or text. Add a passphrase if you want a second factor, and set how long it should live and how many times it can be opened.
-
02
Share the link
Send the one-time link through any channel you like. The secret itself never travels over that channel — only a pointer to it does.
-
03
It self-destructs
The recipient reveals it once and the record is deleted. Nothing is left to find later in a backup, a log, or a forwarded message.
Built for secrets that matter
Every protection you would want on a one-time secret, and nothing you have to configure before it works.
-
AES-256 at rest
The payload is encrypted before it reaches the database, so a dump of the table is not a dump of your secrets.
-
Passphrase lock
Require a phrase before the secret is shown. It is stored only as a bcrypt hash, so we cannot recover it and neither can anyone else.
-
Time-based expiry
Anywhere from 15 minutes to 3 months. When the clock runs out the record is deleted, whether or not it was ever opened.
-
View-count limit
From a single read up to a hundred. The link stops working the moment the count is reached.
-
Burn on read
One-and-done mode wipes the secret the instant it is first revealed, so nobody stumbles on it a month later.
-
Viewer can delete
Optionally let the recipient destroy it themselves once they have what they needed, rather than waiting for the timer.
-
History and audit trail
Every secret you have sent — live, expired or deleted — with view counts and time remaining, in one list.
-
One-click reveal
Skip the confirmation screen where the handoff is time-sensitive and the recipient is already expecting it.
-
Throttled reveals
The reveal endpoint is rate limited, so a passphrase cannot be worn down by repeated attempts from one source.
What teams use it for
Any moment you would otherwise paste a sensitive value into a chat window.
-
Onboarding credentials
A temporary password or SSH key for a new starter, gone once they have logged in and set their own.
-
API key handoff
A production key to a contractor or client, without it being forwardable, archivable, or sitting in a mailbox for a year.
-
Payment details
Card or bank details to an accountant, without them living in a chat log indefinitely afterwards.
-
Incident access
Database passwords or VPN credentials during an outage, auto-deleted once the team is in.
-
Licence keys and codes
A licence key or a set of 2FA backup codes that can be retrieved exactly once, which is the point of them.
-
Client handover
Final admin passwords and access tokens at the end of an engagement, with no paper trail left behind.
Why not just use Slack or email?
Because of what happens to the message afterwards. A secret pasted into a chat is a secret that now lives in a search index, a backup, and everyone's local cache.
| Channel | Encrypted at rest | Auto-deletes | Expiry control | View tracking |
|---|---|---|---|---|
| Secret Push | ||||
| Slack / Teams | — | — | — | — |
| — | — | — | — | |
| SMS | — | — | — | — |
Questions about Secret Push
Anything not covered here? Ask us directly.
How is the secret encrypted?
With AES-256 before it is written to the database, so the stored row is ciphertext rather than your value. This is encryption at rest with a key we hold — it protects against a database compromise, but it is not end-to-end encryption, and we do not claim otherwise. Add a passphrase if you need the contents to be unreadable without something only the recipient knows.
What happens when the secret is read?
With burn-on-read enabled, the record is deleted immediately on the first successful reveal. Otherwise the view count is decremented and the record is deleted once it hits zero, or when the expiry time passes — whichever comes first.
What if the link is never opened?
It is deleted at the expiry time regardless. An unopened secret does not sit around indefinitely waiting for someone to find the link later.
Can I stop someone brute-forcing the passphrase?
That is already on. The reveal endpoint is rate limited, so repeated attempts from the same source are rejected rather than answered. The passphrase itself is stored only as a bcrypt hash.
Can I see whether it has been read?
Yes. Your dashboard lists every secret you have sent with its view count and time remaining, so you can tell whether the handoff landed without asking.
How long can a secret live?
From 15 minutes to 3 months. Shorter is better: pick the smallest window that gives the recipient a realistic chance of opening it.
Is it available on the free plan?
Yes, on every plan including free. Creating secrets through the REST API is a paid feature; creating them in the dashboard is not.
What should I not send through it?
Anything you would not be prepared to rotate. A one-time link reduces exposure — it does not eliminate it, so treat a shared credential as one that should be changed once the recipient is set up.
Stop texting passwords
Your first secret link takes about thirty seconds. Free on every plan, no card needed.