Skip to content
Get early access

What is unrecoverable

Zero-knowledge means no server-side reset. That is the property that makes a breach of our infrastructure worthless, and it is the same property that makes some situations final.

The next section says “your data is unrecoverable” in several different ways, and every one of them is true. But it is worth being precise about the size of that, because the phrase invites you to picture something worse than what usually happens.

Most of what belongs in an environment file can be reissued from wherever it came from. A DATABASE_URL is in your cloud console. A Stripe key is a click away from being rolled. An OAuth secret regenerates. A test-mode key costs nothing to replace.

So the realistic cost of losing a vault is an afternoon of rotating credentials and telling your team you have done it — not the loss of the only copy of something. That is genuinely bad, and it is a different order of bad from what a password manager losing your vault means, where the stored value often is the only copy in existence.

None of that reduces the case for writing your Recovery Kit down. It just means the failure you are insuring against is usually a lost day rather than a lost company.

You lost your master password and your Recovery Kit, and you work alone.

There is no path. Not a support escalation, not a waiting period, not a legal process. The key that decrypts your data was derived from two things you no longer have, and no copy of it exists anywhere else. We cannot reset what we cannot read.

You lost both factors, you are on a team, but the data was never shared.

Admin-assisted recovery restores what a grant-holding admin can re-wrap. If nobody else ever held a key for an environment, there is nothing to re-wrap.

Every grant-holder for an environment has left.

Same reason. The key exists only inside wrapped blobs addressed to people, and if none of those people remain, the environment is ciphertext with no reader.

Payload history from before a rotation.

Rotation destroys the previous key. Older versions become unreadable to everyone who did not retain it. That is what makes revocation real, and it is not reversible.

Your personal overrides, if you go through admin-assisted recovery.

That path mints a new key pair, and your personal overrides were encrypted under a key derived from the old one. Nobody else ever held it — that was the point — so nobody can bring them back. Shared values return; your personal values over them do not.

Situation Path
Forgot your password, have the Recovery Kit Personal recovery. Key pair unchanged, grants and personal overrides intact
Lost both, on a team, data was shared Admin-assisted. Shared environments only; personal overrides destroyed
Lost the Kit, still know your password Change your password — that mints a new Kit. Do it before you need a new device
New device, have password and Secret Key Just unlock. This is not recovery, it’s the normal path

The obvious feature request is an emergency server-side key. It would solve every case above, and we will not build it, because a server that can decrypt your secrets under any circumstance is a server that can decrypt your secrets — and every claim on the security pages would become false.

An escape hatch that only opens for good reasons is a policy. A key that does not exist is an architecture. The whole product is a bet that the second is worth more, and adding the first would mean we did not believe our own pitch.

Concretely: it would mean a breach of our infrastructure exposed your secrets, an insider could read them, and a subpoena could compel them. Those are exactly the three things this design exists to make impossible.

Write down the Recovery Kit. Setup makes you acknowledge it because it is the one irreversible thing in the product, and the acknowledgement is deliberate friction rather than a checkbox to click through.

Put it in a password manager, or print it and file it. Not in the repository whose secrets it protects.