Create secrets, choose when they expire.
Passwords, API keys and env vars are encrypted in your browser before anything is sent. Keep them in a vault, hand one over as a link that dies on your schedule, or issue a scoped key for one app that expires on the day you pick.
- Encrypted in this tab
- An expiry you choose
- A vault with history
- No analytics on this page
Share one now, no account
Expires in 1 day or after 1 view, whichever comes first.
Anonymous links are one view and expire within 24 hours. Sign in for more views, longer expiry, and saved defaults.
Encrypted in this tab before it is sent. No account, and no analytics on this page.
- 01
Typed
In this tab
A password, a token, a .env file, a link or a small file.
- 02
Sealed
In this tab
Encrypted with AES-256-GCM under a key made here. Only the ciphertext is sent.
- 03
Linked
In this tab
The key is written after the # in the link, the one part of a URL a browser never sends.
- 04
Counting down
On the server
The views and the lifetime you chose run down. Opening the link spends nothing; only a reveal does.
- 05
Gone
On the server
Deleted in the same step that hands it over, or when the clock runs out. The link then answers as if it never existed.
Choose when it expires
A view count, a lifetime, and a passphrase if you want one. The server enforces all three, and tells nobody which one ended it.
Lifetime
Counted from the moment it is created
No account
Up to 1 day
- 1 hour, available
- 1 day, available
- 7 days, not on this tier
- 30 days, not on this tier
Signed in
Up to 30 days
- 1 hour, available
- 1 day, available
- 7 days, available
- 30 days, available
Views
Each reveal spends one; the last one deletes it
- 1 views, on every tier
- 2 views, signed in
- 3 views, signed in
- 5 views, signed in
- 10 views, signed in
- 20 views, signed in
- 50 views, signed in
- 100 views, signed in
No account: 1 view, always. Signed in: any of these, up to 100.
- A preview cannot burn it
- Opening the link shows a static page that uses up nothing. Only an explicit reveal spends a view, so a chat app or a link scanner cannot destroy it first.
- A dead link says nothing
- Burned, expired, never existed, or lost a race with another reader: each gets the same response, so a dead link does not even confirm that an id was real.
- Guessing destroys it
- If you set a passphrase, a wrong one never uses up a view, and after ten wrong attempts the secret is burned instead of handed over.
- You can end it early
- Creating a link gives you a one-shot burn token. It destroys the secret without the link or an account, for when you paste it into the wrong window.
- The key can travel separately
- The result screen also gives you the link without its key, and the key on its own. Send them over different channels and neither channel alone carries the secret.
- A mangled link gets a warning
- A key that arrives as
?key=instead of after#has already been sent to a server. It is never used to decrypt, and the page tells the recipient to treat the secret as compromised.
How it works
The first two steps happen entirely in your browser.
- 01
Keep it
In your browser
Add a password, an API key or a whole .env file to your vault. Each item, its name included, is encrypted in this tab under a key only your passphrase or recovery key can open.
- 02
Share it
In your browser
Send it as a link with the expiry and view count you choose. It is encrypted again under a fresh key that rides after the #, the one part of a URL a browser never sends.
- 03
The link expires
On the server
The recipient presses reveal, and the ciphertext is deleted in the same step that hands it over. The link then responds as if it never existed; your vault copy stays where it was.
The vault
Free with a GitHub or Google account. Sealed in this browser under a key only you can unwrap.
What it keeps
Readable only in your browser.
- Passwords, API keys, env vars and notes, each with a name, tags, an environment and optional notes. Search and filters run in this tab, over decrypted items.
- The last 10 versions of every item, on every plan, so an overwrite can be undone.
- .env import and .env or JSON export, both done in the browser, plus a generator for new random secrets.
- A share button on every item that makes a one-time link, encrypted under its own fresh key.
- The unlocked key in memory only. The vault locks when you close the tab, press lock, or leave it idle for 15 minutes.
- On the server: one envelope per item beside an opaque id, a revision number and timestamps; an audit row per write of an id, an event and a time; and your vault key, wrapped under your passphrase and under a recovery key shown once. A vault nobody opens for 13 months is deleted.
The one thing to know first
Lose your passphrase and your recovery key, and the vault is gone. Neither ever reaches us, so there is no reset email. Setup shows the recovery key once, and the passphrase must be at least 12 characters.
What leaves your browser when you share
Creating a share link sends ciphertext and nothing that can open it.
Stays in your browser
Never transmitted, in any header or request.
- plaintext
- sk_live_4eC39Hq…
- key
- #v1.m8QzL…
- decrypt
- in the recipient's tab
Reaches the server
Held under one key, with your chosen expiry set on it.
- v
- 1
- ct
- 9f3a41c0…c21e
- iv
- fresh, 96-bit
- ttl
- 1 day
- views
- 1
- passphrase
- a hash, if you set one
- owner
- your account id, if signed in
- The key is written after the
#in the link. A browser never sends the URL fragment, neither in the request line nor in aRefererheader, so no server, proxy or log on the way ever holds it. - Nothing that identifies a recipient is stored: no title, no address, no IP. If you were signed in, your account id sits beside the envelope so you can burn it later, and that is all.
Keys for every app, with a date on each
The same issuer the *.me.at apps run on. A credential names one app, carries only the scopes written on it, and expires on the day you pick; one board shows who can reach what right now, and takes it back.
trust.me.at
The issuer
- apps it can issue for
- 57
- for itself
- never
- warns at
- 14 d · 3 d
What binds a credential
Every number here is the one the code enforces.
- A credential names exactly one app as its audience and is refused everywhere else. The issuer will never name itself: nothing it mints can open trust.me.at.
- Three scopes, admin, read, write, and none implies another. A credential holding write cannot read, so no grant carries a capability that appears in no row.
- An expiry on every credential: up to 365 days for your own machines, up to 90 days when it is issued to someone else, and admin can never be delegated.
- Rotation plans an overlap window, 48 hours by default and 168 at most, during which both credentials work. The board names the two states that are incidents: both still live after the window, and nothing live at all.
What takes it back
The kill switch is never behind the paywall.
- Revocation is honoured by every app within 60 seconds, and the shared verifier denies a request when the issuer cannot be reached rather than letting it through. Listing and revoking never depend on a licence; only issuing does.
- A credential can be bounded by where it is presented: an address, a network range or a path prefix, first match wins, and an app that asserts no context is denied.
- Every allow and every deny is a row of five fields with the precise reason kept, while the answer on the wire stays uniform.
Where it fits in a day
A posture convinces a reviewer. A named situation is what makes someone remember this exists at the moment they are about to paste a token into a ticket.
Signed in: the vault
Keeping a project’s env vars somewhere safer than a laptop
A side project or a small service has a dozen variables that live in one .env file on one laptop. Import the file into the vault, tag it by environment, and export it again on the next machine without the values ever sitting in a repository or a chat.
Signed in: the vault
The credentials that have no other home
Recovery codes, a registrar login, the root key nobody uses until the day everything depends on it. The vault keeps them encrypted, searchable by name in your browser, and versioned in case one is overwritten.
The vault, or the share form
Handing a credential to a new joiner or a contractor
A password, a VPN profile or a first API token has to reach someone whose accounts do not exist yet. Share it from the vault as a link, and by the time the onboarding doc is archived the link is dead.
Signed in: vault history and share links
Rotating a shared key
Update the item in the vault (the old value stays in its history), then share the new one with a small view count and a short expiry. Better than a pinned message, which is still a live credential next quarter.
Pro: ask links
Collecting a secret from a customer
Asking a customer to paste a token into a support thread keeps it in your ticketing system forever. With an ask link they encrypt it in their browser, only you can open it, and the helpdesk never stores anything readable.
Pro: machine keys
Delivering a credential out of a pipeline
A job that hands a generated credential to a person can push ciphertext to the REST API with a bearer key and output only the link. No cookies, no session, and no plaintext on the wire.
Pro: fleet access
Giving a job or a customer access to one app, until a date
A deploy job needs to call one of the *.me.at apps, or a customer needs read access to one for a quarter. Issue a credential that names that one app, carries the scopes it needs and nothing more, and expires on the date you set. When the quarter ends, revoke it from the same board, and the app stops honouring it within a minute.
Who it's for
One of you has a handful of secrets with no good home. The other is deciding whether a third party should hold your credentials at all.
For the secrets you look after
You have passwords, API keys and recovery codes with no good home: a notes app, a .env file on one laptop, a pinned chat message. Every so often one of them has to reach another person.
- A vault for the secrets you look after, encrypted in your browser before anything is sent. Free with a GitHub or Google account.
- Every item keeps its last ten versions, so overwriting the only copy of a key can be undone.
- Paste a .env file to import it, and export any filtered set back out as .env or JSON. Both happen in your browser.
- Share any item as a link that stops working once it is read, so the copy left in a chat log opens nothing.
- Sharing alone needs no account, no email address and nothing to install. The form at the top of this page is all it takes.
- Creating a link shows you a one-shot burn token. It destroys the secret without the link and without an account, in case you pasted it into the wrong window.
- An optional passphrase guards a link. A wrong one never uses up a view, and repeated guessing destroys the secret.
- Your vault opens with your passphrase or with a recovery key shown once at setup. Lose both and nobody, us included, can open it again.
For an organisation
You are deciding whether a third party may hold your credentials, for months rather than minutes. What matters is where the ciphertext rests, who can read it, and what the tool does on its worst day. Telemetry, blast radius and disclosure are covered on the plans page.
- The server never holds a decryptable secret. A vault item is ciphertext beside an opaque id, a revision number and timestamps. A share link is ciphertext with the expiry you chose set on the row.
- Item names, tags, environments and notes are encrypted with the value, so the store cannot say which credentials you keep. Audit rows are an id, an event and a time.
- Storing, reading and deleting vault items, revoking a machine credential and collecting what someone sent you never depend on a licence. A plan only changes how many items a vault holds, and a test holds the routes to that.
- A licence key is a signature checked locally against a public key you hold. Serving a request calls no licence server, so your uptime does not depend on ours and your usage is not reported anywhere.
- A cookie-free REST API accepts ciphertext from CI and scheduled jobs, authenticated by a bearer key that is shown once and stored only as a hash.
- Ask links let someone outside your organisation send you a secret without an account of their own: they encrypt in their browser and only you can open it.
- Access to one of the *.me.at apps is issued here as a scoped credential: it names one app as its audience, carries only the scopes written on it (read, write or admin, and none implies another), and expires on the day you pick. Shown once at mint, stored only as a hash.
- One board lists every credential you have issued and takes any of them back; every app honours the revocation within a minute. Rotation runs through a bounded overlap window so both credentials work while each consumer is updated, and a digest warns before one expires silently.
Not built yet
- Reading vault items from a CLI or a CI job. Vault items open only in a browser today, because a machine would need the vault key.
- SSO. Sign-in through your own identity provider over OpenID Connect is built and switches on once an instance is configured with an identity-provider client. Until then everyone signs in with GitHub or Google.
- Shared vaults, workspaces and roles. A self-hosted licence is sized by seats, but every vault, secret, key and ask link still belongs to exactly one account.
- A downloadable self-host bundle. The deployment setup, the licence and the export boundary are decided; the public source export is not out yet.
What the encryption does not cover
The promise is the key never leaves your browser, and we never receive it. It is not "we cannot read your secrets": this server ships the JavaScript that handles the key, so only a client you have audited, or an instance you run yourself, gives the stronger guarantee.
Outside the threat model
- Browser extensions with page access on the tab where a secret is typed or revealed.
- Both people's browser history, which keeps the full URL for the life of the secret. Burning on read reduces this risk but does not remove it.
- A weak vault passphrase, against someone holding a copy of the datastore. They can guess offline, and only the passphrase and the slow key derivation stand in the way.
- A malicious operator of a hosted instance. Self-hosting removes this one.
Anonymous, signed in, Pro
Hitting a limit gets a refusal, never a charge. A licence only gates creating new paid things; opening, editing and destroying what already exists never depends on it.
Anonymous
No account.
- One view.
- Up to 24 hours.
- Up to 16 KB of ciphertext.
Signed in
Free, with GitHub or Google.
- Up to 100 views.
- Up to 30 days.
- Up to 64 KB of ciphertext, and defaults you can save.
- A vault for up to 50 secrets, with version history.
- A metadata-only history of your share links that you can burn from, and your own limits before you meet one.
Pro
Paid.
- A vault for up to 500 secrets.
- Ask someone to send you a secret: they encrypt in their browser, and only you can open it.
- Machine keys for the REST API, shown once when created and stored only as a hash.
- Fleet access: issue a scoped, dated credential for one app, and rotate it through an overlap window.
- An audit trail of created, revealed, burned and expired.
Run it yourself
Running your own instance takes the operator out of the threat model.
- Storage is standard Redis or Upstash: one key per share link with the expiry you chose, and one per vault item.
- The licence is checked offline, with a 7-day grace window after it expires. An instance you run never phones home to keep serving.
- The deployment files ship with the app: a compose file, a reverse-proxy config, and an env template for the variables it needs.
- Not downloadable yet. The licence, the deployment setup and the export boundary are settled; the public source export is not out, and the footer names the licence the core ships under.
Questions
- Can you read my secrets?
- Not from what we store. A vault item and a share link are both stored as ciphertext. The vault key is wrapped under your passphrase and a recovery key that never reach us, and a share link’s key travels in the URL fragment, which a browser never sends. The limit: this server sends the JavaScript that handles those keys, so a compromised server or CDN could in principle ship code that steals them. Only a client you have audited, or an instance you run yourself, closes that gap.
- What if I forget my vault passphrase?
- Then the vault cannot be opened, by you or by us. It unlocks with your passphrase or with the recovery key shown once at setup, and either one can set a new passphrase. Lose both and the data is gone for good. That is the cost of a server that never holds a key, and setup asks you to save the recovery key before the vault exists.
- Is this a password manager?
- No. There is no autofill and no browser extension, and nothing fills a login form for you. It is a place to keep the credentials a person or a team looks after (API keys, env vars, recovery codes, shared logins) and a safe way to hand one over.
- What do you log?
- Nothing that identifies anybody. No recipient, title or IP address is stored beside a secret, and vault item names are encrypted. A signed-in account builds up lifecycle rows of an id, an event and a time (created, revealed, burned, expired, and every write to the vault), and the pages that can hold plaintext send no analytics at all.
- Where does the ciphertext actually sit?
- In Redis or Upstash. A share link is one key with the expiry you chose. A vault is a key per item plus the wrapped vault key, kept while you use it and deleted after 13 months untouched. Nothing goes into a relational database. If you run it yourself, the datastore is yours, and so is the residency answer.
- What if a link scanner opens a share link first?
- It cannot spend it. Opening a share link shows a static page, and only an explicit reveal (a POST) burns the secret. This does not rely on a list of known scanners, so it also holds for crawlers nobody has heard of yet.
- How much does a dead link give away?
- Nothing. Burned, expired, never existed, or lost a race with another reader: all four get the same response, so there is no way to tell whether an id was ever real. For the same reason a wrong passphrase reveals nothing, and repeated guessing destroys the secret.
- Can it manage access to the other me.at apps?
- Yes, and it is how the fleet itself does it. A fleet access credential names one app as its audience (never trust.me.at itself), carries a closed scope set, and expires on a date you choose. Each app checks it through one shared verifier that denies a request when the issuer cannot be reached, and a revoke is honoured within a minute. Issuing one is Pro; listing and revoking never depend on a licence. The issuer indexes what it issued, never what it carried: no app’s secrets pass through it.
- Do you have SSO, seats or shared vaults?
- Partly. Sign-in through your own identity provider over OpenID Connect is built and switched on per instance once an identity-provider client is configured. A self-hosted licence is sized by seats. Every vault and secret still belongs to exactly one account, and there is no shared workspace or role concept yet.
- What happens when a licence lapses?
- Creating new paid things stops after a grace window, and nothing else changes. Your vault keeps opening, editing and deleting. Listing and revoking machine keys, cancelling an open ask link, collecting a secret someone already sent you and checking your remaining quota all keep working, and a test fails if one of them moves behind the licence.
- Can we run it on our own infrastructure?
- Yes, inside your own network: the deployment files ship with the app, storage is standard Redis or Upstash, and the licence is checked offline with no call home. The public source export is not published yet, so for now it starts with a conversation instead of a download.
Not built yet
In progress
- A first-party CLI
- Credential storage and the device sign-in flow exist as policy code with no binary that calls them. Until a CLI ships, the REST API is driven with the curl recipes in MACHINE.md.
- SSO
- OpenID Connect sign-in through your own identity provider is built and stays off until an instance is given an identity-provider client, which only the operator can create. Sign-up goes through an identity provider either way.
Decided, not built
- A self-host download
- The deployment setup, the licence and the export boundary are decided and written down, but the public source export is not out. For now, running it on your own network starts with a conversation.
Under consideration
- Reading vault items from a CLI or CI job
- Vault items open only in a browser today. A CLI or CI job would need the vault key on a machine, and how a machine may hold it safely is still an open decision.
- Shared vaults, workspaces and roles
- A self-hosted licence counts seats, but every vault, secret, machine key and ask link belongs to exactly one account. Sharing a vault between people needs an organisation model and a way to share a vault key, and neither exists yet.
- Log export
- The audit trail is per account, and each row is an id, an event and a time. Streaming it to your own log destination is unbuilt.
- A DPA and compliance attestations
- No data processing agreement has been drafted and no certification has been pursued. What exists is the threat model, the blast-radius inventory and the source. Some reviewers will accept that and some will not.
- Invoicing and an SLA
- Checkout runs through pay.me.at. Invoices on your own paperwork, procurement forms and an uptime commitment are all unbuilt.
Try it with something harmless
Share something from the form at the top, free and with no account, or sign in and set up your vault. Evaluating it for an organisation? The plans page covers the licence and self-hosting.
Card details are never entered on trust.me.at. Pro checkout happens on pay.me.at.