Best Self-Hosted Dead Man's Switch Software (2026)

Best Self-Hosted Dead Man's Switch Software (2026)
A dead man's switch is a mechanism that triggers automatically when you stop responding. In the digital world, this translates to software that monitors your liveness and takes predefined actions --- like notifying your family, releasing encrypted documents, or transferring access credentials --- when you fail to check in within a specified window.
Self-hosting a dead man's switch gives you complete control over the most sensitive data you will ever store: the instructions and credentials your loved ones need after you are gone. No third-party SaaS provider can shut down, get acquired, or suffer a breach that exposes your succession plan.
This roundup compares six self-hosted dead man's switch solutions available in 2026. We evaluated each on encryption, notification channels, ease of deployment, maintenance burden, and the overall trust model.
Why Self-Hosted Matters for Dead Man's Switches
Before diving into the comparison, it is worth understanding why self-hosting is particularly important for this category of software.
A dead man's switch holds data that is, by definition, needed when you are no longer around to manage it. If that data lives on a third-party server, you are trusting that company to remain operational, solvent, and secure for an indefinite future. You are also trusting that their encryption model is sound and that they will not be compelled by legal action to hand over your data.
Self-hosting eliminates the single point of failure. Your data lives on hardware you control, encrypted with keys you manage, and the software runs on code you can audit. The tradeoff is operational overhead --- you need to keep the server running, updated, and accessible.
The best self-hosted dead man's switch software minimizes that operational overhead while maximizing the security guarantees.
Feature Comparison Table
| Feature | Burning Ash Protocol | LastSignal | Seppuku | Posthumous | storopoli/dead-man-switch | EmergencyWP |
|---|---|---|---|---|---|---|
| License | AGPL-3.0 | GPL-3.0 | MIT | MIT | MIT | GPL-2.0 |
| Language | Go + Next.js | Python | Rust | Python | Rust | PHP (WordPress) |
| Encryption | AES-256-GCM + Shamir SSS | AES-256 | None (relies on GPG) | AES-256-CBC | None | WordPress encryption |
| Threshold Recovery | Yes (K-of-N Shamir) | No | No | No | No | No |
| Liveness Checks | Configurable (HCIT/HCRT/HCRAC) | Email-based | Cron-based | Email-based | Cron-based | WordPress cron |
| Notification Channels | Email, SMS, WhatsApp, Telegram | |||||
| Document Storage | Encrypted will (GDrive, Dropbox, S3, SFTP, OneDrive) | File attachments | None | File attachments | None | WordPress media |
| Web UI | Full dashboard | Basic | None (CLI) | Basic | None (CLI) | WordPress admin |
| Docker Support | Official Compose | Community | Dockerfile | Dockerfile | None | WordPress Docker |
| Active Development | Yes (2026) | Sporadic | Archived | Sporadic | Minimal | Plugin updates |
| SaaS Option | Yes (Free/Pro) | No | No | No | No | No |
Burning Ash Protocol (BAP)
Burning Ash Protocol is a purpose-built digital will and dead man's switch system written in Go with a Next.js frontend. It is the most feature-complete option in this comparison.
How It Works
BAP uses a three-parameter liveness check system. The Host Check-In Interval (HCIT) defines how often you are pinged. The Host Check-In Response Time (HCRT) defines how long you have to respond. The Host Check-In Response Action Count (HCRAC) defines how many consecutive missed check-ins trigger the Will Transfer Protocol.
When the switch triggers, BAP does not simply send a password to your Survivors. Instead, it uses Shamir's Secret Sharing to split the Data Encryption Key for your will across multiple Survivors. A configurable threshold (K-of-N) of Survivors must cooperate to reconstruct the key and access the encrypted documents. This means no single Survivor can access your data alone.
Documents are encrypted with AES-256-GCM, and the encryption keys themselves are protected by a master key. Notifications go out through Email, SMS, WhatsApp, or Telegram, depending on what you configure.
Deployment
BAP ships with an official Docker Compose configuration. A typical homelab deployment takes under 15 minutes. It uses SQLite for development and PostgreSQL for production, with automatic migrations at startup.
Pros
- The most comprehensive encryption model of any option in this list, combining authenticated encryption with threshold key recovery
- Multi-channel notifications ensure Survivors actually receive the alert
- Configurable liveness parameters let you tune false-positive risk
- Active development with a clear roadmap
- Both self-hosted and SaaS deployment modes from the same codebase
- Full web dashboard for non-technical users
Cons
- More complex than simpler alternatives if you only need basic email notification
- Requires a running server with reliable uptime (though this applies to all options)
- Newer project compared to some alternatives
Best For
Users who want the most secure and feature-rich self-hosted dead man's switch, especially those with multiple Survivors who should not individually have full access to the will.
LastSignal
LastSignal is a Python-based dead man's switch that focuses on simplicity. It sends periodic liveness check emails and triggers notifications if you fail to respond.
How It Works
LastSignal sends you an email at a configured interval. If you do not click the confirmation link within the response window, it sends a follow-up. After a configurable number of missed confirmations, it delivers your pre-written messages to your designated recipients via email.
The system stores messages encrypted with AES-256. There is no threshold recovery or key splitting --- your recipients receive the full decrypted message directly.
Deployment
LastSignal runs as a Python application with a basic web interface. It requires a mail server or SMTP credentials for sending and receiving emails. Docker deployment is available through community-maintained images.
Pros
- Simple to understand and configure
- Mature codebase with a straightforward architecture
- Email-based check-in requires no app installation
- Low resource requirements
Cons
- Email-only notifications --- if your recipient misses the email, there is no fallback channel
- No threshold recovery --- each recipient gets the full message
- No encrypted document storage --- you can only send text messages
- Basic web UI with limited configuration options
- Sporadic development activity
Best For
Users who want a simple, email-based dead man's switch without the complexity of encryption key management or multi-channel notifications.
Seppuku
Seppuku is a Rust-based dead man's switch that takes a minimalist, Unix-philosophy approach. It is a command-line tool that executes arbitrary scripts when a timer expires.
How It Works
Seppuku runs a countdown timer. You reset the timer by running a command (typically via cron or a manual trigger). If the timer reaches zero, Seppuku executes a configured script. That script can do anything --- send emails, delete files, publish documents, or trigger external APIs.
There is no built-in encryption, notification system, or web interface. Seppuku is purely a timer-and-trigger mechanism. You build everything else yourself.
Deployment
Seppuku is a single Rust binary. You compile it, configure the timer and trigger script, and run it. A Dockerfile is available for containerized deployment.
Pros
- Extremely lightweight and fast
- Maximum flexibility --- the trigger script can do anything
- Small attack surface due to minimal code
- Rust memory safety guarantees
- MIT license with no copyleft obligations
Cons
- No built-in encryption, notification, or document storage
- Requires significant scripting to build a complete dead man's switch
- No web UI --- CLI only
- Repository is archived with no active development
- The flexibility is also a liability: you must correctly implement every security-sensitive component yourself
Best For
Developers and sysadmins who want a minimal timer mechanism and prefer to build the notification and encryption layers themselves.
Posthumous
Posthumous is a Python-based system that lets you write encrypted messages to be delivered after your death. It shares conceptual DNA with LastSignal but targets a slightly different use case.
How It Works
Posthumous stores encrypted messages that are delivered to recipients when the dead man's switch triggers. Liveness checks are email-based, similar to LastSignal. The system uses AES-256-CBC encryption for stored messages.
Deployment
Posthumous runs as a Python web application with a basic interface. Docker deployment is available. It requires SMTP credentials for email delivery.
Pros
- Focused on the message delivery use case
- Straightforward setup process
- AES-256 encryption for stored messages
- Dockerfile included
Cons
- Uses AES-256-CBC rather than GCM, which lacks built-in authentication (susceptible to padding oracle attacks if not carefully implemented)
- Email-only notifications
- No threshold recovery
- No document storage beyond text messages
- Limited development activity
- Basic web interface
Best For
Users who want a simple "send a message after I die" system without complex encryption or multi-channel delivery requirements.
storopoli/dead-man-switch
This is a minimal Rust implementation of a dead man's switch focused on simplicity and correctness. It is perhaps the most Unix-like option in this comparison.
How It Works
The dead-man-switch binary monitors a timer. You reset it via a simple HTTP endpoint or command-line call. When the timer expires, it sends a notification email. The entire system is designed to be as simple as possible.
There is no encryption, no document storage, and no web UI. It is a timer that sends an email.
Deployment
It is a single Rust binary with minimal dependencies. You configure it via environment variables or a config file and run it. There is no Docker support out of the box, but containerizing a single binary is trivial.
Pros
- Extremely simple and auditable codebase
- Rust memory safety
- Minimal attack surface
- MIT license
- Clean, well-documented code
Cons
- No encryption whatsoever
- Email-only notification
- No web interface
- No document storage
- Minimal development activity
- You must build everything beyond "timer expires, email sent" yourself
Best For
Developers who want the absolute minimum viable dead man's switch and are comfortable building additional functionality on top.
EmergencyWP
EmergencyWP is a WordPress plugin that adds dead man's switch functionality to an existing WordPress installation. It is the only option in this comparison that is not a standalone application.
How It Works
EmergencyWP integrates with WordPress's user system and cron scheduler. It sends periodic liveness check emails to the site administrator. If the administrator fails to respond, it delivers pre-configured emergency messages to designated contacts.
Being a WordPress plugin, it leverages the existing WordPress infrastructure for user management, email delivery, and data storage.
Deployment
If you already run WordPress, installation is standard plugin activation. If you do not run WordPress, this option requires standing up an entire WordPress installation, which is significant overhead for a dead man's switch.
Pros
- Zero additional infrastructure if you already run WordPress
- Familiar interface for WordPress users
- Plugin ecosystem integration
- GPL-2.0 license
Cons
- Requires WordPress --- significant overhead if you do not already run it
- WordPress's security track record adds attack surface
- WordPress cron is not true cron (it fires on page visits, which is unreliable for time-sensitive operations)
- Encryption relies on WordPress's built-in mechanisms, which are not designed for this use case
- Email-only notifications
- No threshold recovery or Shamir's Secret Sharing
- Plugin updates may lag behind WordPress core updates
Best For
WordPress site owners who want dead man's switch functionality without deploying additional infrastructure.
Decision Framework
Choosing the right self-hosted dead man's switch depends on your threat model, technical comfort level, and the complexity of your succession plan.
Choose Burning Ash Protocol if:
You need the most comprehensive solution. You have multiple Survivors and want threshold-based access control. You want multi-channel notifications to ensure delivery. You want encrypted document storage, not just text messages. You are comfortable with Docker Compose deployment.
Choose LastSignal or Posthumous if:
You want a simple, email-based system. You have a single beneficiary or do not need threshold recovery. Your succession plan is a text message, not encrypted documents. You prefer Python-based tools.
Choose Seppuku or storopoli/dead-man-switch if:
You are a developer or sysadmin who wants maximum control. You are comfortable writing your own notification and encryption scripts. You prefer minimal, auditable codebases. You want a building block, not a complete solution.
Choose EmergencyWP if:
You already run WordPress and want to minimize additional infrastructure. Your succession plan is simple enough for email-based delivery. You are comfortable with WordPress's security model.
Security Considerations for All Options
Regardless of which tool you choose, self-hosting a dead man's switch requires attention to several security fundamentals.
Server reliability matters more than usual. If your server goes down and you cannot check in, the switch may trigger falsely. Conversely, if the server goes down permanently, the switch will never trigger. Consider your hosting environment's reliability carefully.
Backups of the switch itself are critical. Your dead man's switch configuration, encryption keys, and beneficiary data need their own backup strategy. If the switch's data is lost, it cannot function.
Update discipline is non-negotiable. A dead man's switch is a high-value target. Keep the software, operating system, and all dependencies current.
Network security protects the trigger mechanism. If an attacker can reach the check-in endpoint, they could potentially keep the switch from triggering. Use firewall rules, VPN access, or other network-level controls.
Test the entire flow regularly. Configure a test beneficiary (yourself, on a separate email) and let the switch trigger in a controlled environment. Verify that notifications arrive, encryption works end-to-end, and the recovery process is something your actual beneficiaries can follow.
Conclusion
The self-hosted dead man's switch landscape in 2026 ranges from minimal timer scripts to comprehensive digital will platforms. For most users with non-trivial succession plans, Burning Ash Protocol offers the strongest combination of security (AES-256-GCM with Shamir's Secret Sharing), usability (full web dashboard), and operational maturity (Docker Compose deployment, multi-channel notifications).
For developers who prefer to build their own solution from minimal components, Seppuku and storopoli/dead-man-switch provide clean foundations. For WordPress users, EmergencyWP avoids additional infrastructure. And for users who want simplicity above all else, LastSignal and Posthumous deliver straightforward email-based dead man's switches.
The most important thing is that you choose something. The worst dead man's switch is the one you never set up.
Related Articles

LastSignal vs Burning Ash Protocol vs Posthumous: Which Open-Source Dead Man's Switch?
An in-depth three-way comparison of LastSignal, Burning Ash Protocol, and Posthumous -- the leading open-source dead man's switch projects for digital estate planning.
Read Protocol
Deploy Burning Ash Protocol on Your Homelab in 15 Minutes
A step-by-step tutorial for deploying Burning Ash Protocol on your homelab using Docker Compose, with reverse proxy setup (Caddy or Nginx), DNS configuration, and HTTPS.
Read Protocol
Digital Will for Developers: A Sysadmin's Guide
A practical guide for developers and sysadmins to organize SSH keys, API tokens, infrastructure secrets, CI/CD credentials, DNS management, and server access for digital estate planning.
Read Protocol
Building a Dead Man's Switch API: Architecture Decisions
A technical deep-dive into Burning Ash Protocol's Go API architecture: Chi router, GORM, scheduler design, liveness check polling, encryption layer, and the engineering tradeoffs behind each decision.
Read Protocol