Plans

The Pro column lists exactly the actions the service puts behind a licence. It is generated from the same code that enforces the licence, so it cannot drift from what the service does.

A licence gates the creation of new paid capability. It never gates seeing, retrieving, or destroying what already exists.

So if a key lapses (or was never there), these all keep working, exactly as before:

The machine API that a credential authenticates against has no licence check at all, so a scheduled job holding a valid key keeps working when an entitlement changes elsewhere. Putting revocation behind the licence would not disable any credential. It would only stop you from disabling one, at the moment you most need to.

When Pro lapses you can no longer create paid things such as a new key or a new ask link, and the audit trail closes. None of that takes away anything you already hold.

The questions that cannot be answered with a yes yet are listed under Not built yet, with how far along each one is.

The grace window also covers clock skew, so a slightly wrong clock keeps the instance serving.

Only the ceilings that actually move are listed. Everything absent from this table is the same on every tier, including all four of the controls a tier is never allowed to move: revoking, listing, collecting what you already own, and the access log that shows a leaked credential being used.

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.

What this service promises: the key never leaves your browser, and we never receive it. It is not "we cannot read your secrets". This server sends the JavaScript that handles the key, so a compromised server or CDN could in principle ship code that steals it. Only a client you have audited, or an instance you run yourself, gives the stronger guarantee. That holds on every plan.

The full threat model