Death Plan Switch offers self-hosted contingency for solo admins

Released on October 24, 2026, Death Plan Switch is a self-hosted application designed to help solo administrators manage their digital responsibilities in the event of an emergency. Created by Jeremy, this tool addresses the common oversight of who maintains critical infrastructure when the primary admin is no longer available to respond.

What happened

The application functions as a digital dead man’s switch, requiring the administrator to check in regularly to confirm they are active. Once a week, the system emails a unique link to the owner. To register a successful check-in, the user must open the link and manually press a button on the resulting page. This two-step process prevents automated email scanners from accidentally marking the admin as present, ensuring that silence truly indicates absence.

If a check-in is missed, the system does not immediately alert external contacts. Instead, it sends reminders to the owner and waits. After three days of inactivity, the application contacts a nominated next of kin to verify the situation. This person can confirm that everything is fine or report a problem. If there is still no response, the system eventually sends prewritten messages to designated contacts, such as IT successors or clients. The entire documented process can take up to thirteen days from the last successful check-in, allowing ample time to rule out false alarms like vacations or minor illnesses.

Key details

• The application is written in PHP 8.1 or newer and uses SMTP for email delivery.
• It relies on a scheduled job that runs every fifteen minutes to check status and send notifications.
• No database is required; configuration and messages are stored in plain text within a protected data directory.
• Contacts must confirm their roles before the switch can be armed, ensuring everyone is aware of their responsibilities.
• The project is free and released under the MIT license, with source code available on GitHub.
• There is no official Docker Compose deployment provided in the current installation instructions.

Background

A dead man’s switch is a mechanism that activates automatically if the human operator becomes incapacitated. In software contexts, this usually involves monitoring a heartbeat signal. If the signal stops, predefined actions trigger. For solo developers and sysadmins, this concept is vital because knowledge about domain renewals, hosting credentials, and client obligations often resides in one person’s head or password manager.

Unlike a password vault, which stores secrets, Death Plan Switch focuses on communication. It directs trusted people to where information lives rather than storing the credentials itself. This distinction reduces security risks while ensuring that successors know whom to call or which accounts need attention. The tool emphasizes rehearsal and annual reviews, recognizing that a plan is only useful if the people involved understand their role.

Why it matters

For teams running self-hosted software, single points of failure are a significant risk. While backups protect data, they do not preserve context. If a sole administrator disappears, services may lapse, domains may expire, and clients may be left without support. Death Plan Switch provides a structured way to bridge this gap, turning a potential crisis into a managed handover process.

However, the tool introduces its own dependency: it must remain operational to function. If the server hosting the switch goes down, or if the scheduled job fails, the safety net disappears. This creates a paradox where the emergency tool requires the same reliability as the systems it protects. Administrators must ensure the switch is hosted separately from their primary services and monitored independently to avoid silent failures during critical moments.

What you can do

• Host Death Plan Switch on a separate server or infrastructure provider from your main services to isolate risks.
• Monitor the application’s health endpoint from an external service to detect if the scheduler or server fails.
• Rehearse the full notification workflow with test contacts to ensure emails deliver and recipients understand the process.
• Store actual credentials and recovery documents in a separate, secure location referenced by the switch’s messages.
• Review and update contact roles and instructions annually to keep the plan relevant and accurate.
• Ensure the data directory containing SMTP passwords and messages is inaccessible from the web, as the app stores them in plain text.