Open-Source Dead Man's Switch: Why Verifiability Matters for Something This Important

A dead man's switch asks something unusual of whoever operates it: keep a secret perfectly for years, then deliver it exactly once, after the one person who could catch a mistake is gone. With a closed service, that means trusting a company's integrity, competence, and continued existence across a horizon measured in decades. Open source changes the shape of the bet. "I can read what it does, and I can run it myself" is a trust property you can verify today, not a promise you hope ages well.

That's the whole argument in one paragraph. The rest of this piece makes it properly, including the part most open-source advocacy skips: self-hosting a continuity tool creates a continuity problem of its own, and if verifiability is the argument, the argument has to survive a full accounting.

Why this category is different from normal software trust

Three properties, in combination, make a dead man's switch unlike almost anything else you run.

The horizon is decades, not billing cycles. Most software you evaluate continuously. It degrades, you migrate. A switch you configure at forty may need to fire at eighty-five. Companies get acquired, pivot, and sunset products on far shorter timescales than that, and the failure mode isn't dramatic. It's a polite shutdown notice arriving in an inbox you may no longer be reading.

It must fire exactly once, and the worst failure is unobservable. A false positive, releasing your most private words while you're alive and well, you would at least witness and could contain. A false negative is silence at precisely the moment the system existed to speak, and it's discovered by no one, because the only person who knew what to expect is gone. There is no retry and no bug report from the person who matters. Reliability here has to be structural, not reactive.

The payload is maximally private. Final words, credentials, and instructions for the people you trust most are by definition the most sensitive material you have. "Trust our encryption" is a large ask when the source is closed and the horizon is long.

Ordinary SaaS trust is renewable. You re-evaluate every month and leave when quality drops. This category asks you to prepay trust across decades, against failures only other people will observe. That mismatch is why verifiability isn't a nice-to-have here. It's the property everything else rests on.

What "I can read it and run it myself" actually buys

Claims become checkable. If a service says messages are encrypted client-side before upload, open source lets anyone confirm where keys are generated, what the server can actually read, and what leaves your machine. With a closed system, the encryption story is marketing until proven otherwise, and there is no way to prove otherwise.

Continuity decouples from the company. If the operator shuts down, open code keeps existing. You can run it, fork it, or hire someone who will. The project's fate and the company's fate stop being the same fact.

Exit is real. Self-hostable software is the strongest form of no lock-in. Worst case, you take the code and your data and keep going.

Scrutiny compounds. Public code accumulates readers: auditors, packagers, curious engineers. Bugs surface and get fixed in the open, and the issue tracker becomes a track record you can judge for yourself.

Worth stating before going further: open source does not mean audited. Unreviewed open code is just code that could have been reviewed. The property that matters is that inspection is possible, by anyone, indefinitely. Closed systems don't offer the option.

And there's a real ecosystem to inspect. LastSignal encrypts messages in the browser before upload and self-hosts with Docker. circa10a's dead-mans-switch ships as a single binary with check-in timers behind a UI, API, and CLI. Seppuku is a .NET take with an extensible module system. Different trade-offs, all of them readable, which is the point.

The part that gets skipped: a self-hosted continuity tool is itself a continuity problem

Here is the irony, stated plainly. A dead man's switch must outlive your attention, and a self-hosted service is the thing in your life most dependent on your attention.

The failure modes are ordinary and quiet:

• The VPS bills to a credit card that gets cancelled by your executor, doing their job correctly.
• The domain lapses, and outbound email starts silently failing.
• An unattended upgrade breaks the mailer in year six and nobody notices, because the whole premise of the tool is that you've stopped checking things.
• The box dies and the switch never fires, or the scheduler misbehaves and it fires early. Both failures are silent by design.
• You were the only person who knew the server existed at all.

None of this is an argument against self-hosting. It is an argument for self-hosting with the same seriousness you'd demand from an operator:

• Give the watchdog a watchdog. External uptime monitoring from a different provider, alerting someone besides you.
• Name a second maintainer. A technical friend or successor who knows the box exists, holds access documentation, and inherits it. A self-hosted dead man's switch with a bus factor of one is a contradiction in terms.
• Prepay the horizon where you can. Multi-year domain renewals, and infrastructure arrangements that don't hinge on next month's card payment.
• Choose boring. Mature stack, few dependencies, minimal moving parts. A cron job and a well-tested script beat an elaborate cluster when the job is to do one thing correctly, years from now.
• Test the real path yearly. Send a trial release to yourself and confirm the mail actually lands.

If that list reads as more operational commitment than you want to carry, that's a legitimate conclusion, and it's why hosted services exist. The middle position worth knowing about is the open core: an operator runs the infrastructure while the code stays public, inspectable now and runnable by you or your successors if the operator ever disappears. This is the approach Aegis DMS is built around. Its core, Aegis Core, is open source and self-hostable at github.com/enegence/aegis. Whichever way you go, that pattern of a service you can use with code you could take over is the one that keeps both failure stories survivable.

A short rubric, whichever way you go

Whether you're evaluating a hosted product or a GitHub repo, the same five questions sort the field:

1. Can anyone verify the encryption story, or only read about it?
2. What happens between a missed check-in and release? Escalation across multiple channels is the difference between a switch and a tripwire.
3. If the operator or server vanishes, what's your recourse? Export, fork, or a named successor?
4. Can recipients act on what arrives, with keys available, formats open, and instructions included?
5. Who else has looked at it? Audits, community history, an issue tracker with real life in it.

We keep a longer version of this rubric in how to choose a dead man's switch app. And if you're working out the broader estate side, meaning what to write, which platform tools to enable, and what should happen to specific accounts, start with our practical guide to digital legacy.

Where to start

If you're going to self-host: pick a maintained project, actually read the delivery and key-handling paths before trusting them, put external monitoring on the box, document everything for one other person, and put a yearly delivery test on the calendar.

If you'd rather not: prefer systems whose core you could inspect and run if you ever had to, and press hardest on question 3.

A dead man's switch is a promise made to people you won't be able to remind. For a promise like that, "verifiable" beats "trust us," and a straight account of the maintenance burden beats a pitch that pretends there isn't one.