Nothing worth stealing
The one field that mentions a login asks where you keep it, not what it is — a note to yourself, for whoever winds things up. It never appears in a client's pack.
Security
The safest thing we did was refuse to hold your passwords.
Torchpass never asks for a client credential, so there is no vault to breach, no master key to leak and no support override to abuse. What it holds is a description of how a website is put together — which is exactly what the person picking it up needs, and worth very little to anybody else.
The decision underneath everything
A handover is knowledge, not keys.
The instinct is to build a vault. We looked at what a client actually has to do when their developer is gone, and almost none of it involves a password.
Their site is on Duda? They ring Duda and ask for a transfer. It is on Vercel from a private repo? They do not need that account at all — any developer can redeploy the code and re-point the domain they already own. Email running through Resend? Two DNS records, in a registrar they control.
None of that is improved by us holding a credential, and all of it is made more dangerous.
Nothing to break early
Because clients are given nothing today, there is nothing for them to log into, poke at, or break while you are still very much alive and responsible for it.
Nothing that expires
Passwords rot. "This site is a Medusa store, the code is in Git, the host is Render, you own the domain" is still true in five years.
Isolation
One client can never see another.
If you look after forty businesses, the failure that would actually embarrass you is not a breach — it is one client opening a document and finding the other thirty-nine in it.
Enforced by the database
Row level security is on every table, scoped to the owner, and the application holds no key that can bypass it. Isolation is not something the code remembers to do — it is something the code cannot avoid.
A pack is one client's
Projects belong to a client, and a pack is assembled from that client's projects alone. There is no view anywhere that lists your other customers to anybody but you.
Dormant until it matters
A client's link works from the day you create it and shows them nothing at all until a release genuinely happens, so it can be handed over years in advance.
The protocol
It cannot go off early, because nothing pushes it.
Most dead-man's switches are a scheduled job that decides something. Ours decides nothing. Which state you are in is worked out from a handful of dates every time anyone looks — your last check-in, the schedule you set, and whether anybody has confirmed.
A job that runs twice cannot release you twice. A job that never runs cannot release you at all. There is no queue to get stuck in and no flag left set by a crash halfway through.
And the rule is written once, in the database, rather than once there and once in the app. Two versions of a rule this consequential eventually disagree, and the one that disagrees is the one that tells forty businesses you have died.
Any single person can stop this, at any point, without giving a reason. Nobody can start it alone.
The asymmetry the whole thing rests on
Threat model
What this protects you from, and what it doesn't.
Any security page that only lists strengths is marketing. Here is both halves, including the parts that are not built.
Defended
- One client seeing another's information. Enforced in the database, not in the code that queries it.
- A client's link leaking before anything has happened. It returns nothing until a release is real.
- An early release caused by a background job running twice, or not at all. Nothing is decided by a job.
- Losing your password. There isn't one — signing in is a link to your email.
- Being wrongly declared gone. You can cancel with one click, and so can any single person you named.
- Your credentials leaking from us. We do not have any.
Not defended
- Us reading what you store. This is not end-to-end encrypted. It is encrypted in transit and at rest, and that is all. Do not put passwords in it — it never asks for them.
- Somebody with access to your email inbox. A sign-in link goes there, and that is the whole account.
- An attestor who confirms maliciously. They still see nothing, the waiting period still runs, and you or anyone else can cancel it — but they can waste your week.
- Anything you never wrote down. Torchpass cannot hand on what it was never told.
- A determined adversary targeting you specifically. There has been no third-party audit, and we are not going to imply there has.
Not built yet
The list nobody publishes.
Torchpass is early. The protocol works and you can drive the whole thing end to end today, but some of what you would reasonably expect is not there, and you should know which parts before you rely on it.
Reminders are manual
Nothing emails you when a check-in is due, and nothing emails the people you named when they are needed. You send them their link yourself. This is the next thing being built.
No end-to-end encryption
Adding it properly means key management, recovery and an audit. Bolting it on now would look like safety without being it, and the thing it would protect is a description of a website.
No independent audit
Nobody outside has reviewed this. When that changes, this page will name who did it and link the report — until then, take the code on its own merits.
Questions
The ones people actually ask.
Do you store my clients' passwords?
No, and there is nowhere to put one. The only field that mentions a login asks where you keep it, so whoever winds things up can find it — and that note never goes into a client's pack.
Can Torchpass staff read what I write?
Technically yes, and we would rather say so than imply otherwise. This is not end-to-end encrypted. What you write is a description of how a site is put together, which is why that trade is acceptable — and why you should not use it as a password manager.
Could it release by mistake while I'm just offline?
Silence alone never releases anything. It takes a missed check-in, then a grace period where only you are contacted, then somebody you named actively confirming, then a final waiting period. Any one of those people can stop it, and so can you, with one click.
What does the person I name actually see?
One question, and nothing else. No client names, no domains, no logins, no packs. Confirming and receiving are separate jobs and they only have the first one.
What if I never name anybody?
Then nothing can ever be released, and Torchpass will keep telling you so. That is the safe failure, but it also means the thing is doing nothing for you.
What happens if Torchpass shuts down?
Print the packs. Every one of them is a plain page designed to be printed and handed to a developer, and it stays just as useful on paper as it is here. That is a deliberately unglamorous answer, and it is a real one.
Read the pack your worst-off client would get.
That document is the whole product. Everything on this page exists to make sure it arrives at the right time, to the right person, and to nobody else.
See how it works