I understand the appeal.
If your digital estate matters, why trust a service with it? Why not run the whole thing yourself, keep the keys local, and remove the middleman?
That sounds clean. It sounds sovereign. It sounds like the right answer for a technical person who has been burned by platforms, subscriptions, acquisitions, and vague privacy policies.
It is still the wrong default for a dead man's switch.
Not because self-hosting is bad. Self-hosting can be excellent for many things. But a dead man's switch is a different kind of system. Its first truly important test may happen when you are dead, incapacitated, unreachable, or no longer able to maintain the infrastructure you built.
That changes the design problem completely.
The system has to outlive your maintenance
A normal self-hosted service can depend on you.
If your media server breaks, you fix it. If a certificate expires, you renew it. If the VPS bill fails, you update the card. If a Docker image needs patching, you patch it. If DNS gets weird, you know where to look.
That is fine for a hobby service, a personal dashboard, a private note system, or a family photo archive.
It is not fine for a continuity system whose job begins when you are no longer available.
A self-hosted dead man's switch depends on a long chain of boring things staying alive:
- a VPS, NAS, or home server that still runs
- a domain that still renews
- DNS records that still point to the right place
- TLS certificates that do not expire at the wrong moment
- outbound email that still gets delivered
- SMS or messaging integrations that still work
- backups that are current and recoverable
- monitoring that someone still sees
- security updates that still happen
- documentation another human can understand
That is a lot of moving parts for something your family may only discover after the person who understood it is gone.
If your inheritance plan depends on infrastructure you personally maintain, you have built a dependency on the one person who cannot be in the loop anymore.
That is backwards.
The Google Drive folder has the same weakness
There is a softer version of the same plan.
Do not run a server. Do not maintain a dead man's switch. Just make a folder on Google Drive, put the important files in it, and tell someone where to look.
That feels much less fragile than a home server. In some ways, it is. Google is better at keeping disks online than you are.
But the failure mode did not disappear. It just moved up a layer.
Who can access the folder if your main Google account is locked behind a phone, passkey, recovery email, or second factor nobody else controls? Are the sharing permissions still correct? Did you put the final version of the document there, or the draft from two years ago? Does the folder explain what matters first, or does it just contain filenames that made sense to you at the time?
And if the folder contains everything, then you have the opposite problem: your family gets a dump of passwords, documents, scans, crypto notes, insurance PDFs, business records, private letters, and random admin files with no release logic and no separation by recipient.
A cloud folder is useful as storage. It is not a handoff.
It can hold the material. It cannot decide when it should be released, who should receive which part, how they should be verified, what they should do first, or what should stay private.
It also cannot keep the payment rails alive.
That matters more than people expect. Once a bank has been notified of a death, accounts and safe deposit boxes can be blocked until the heirs are clear. Bank cards, credit cards, direct debits, and online banking access tied to those accounts can stop as part of that process; KBC Brussels explains this bluntly in its bereavement guidance.
A Drive folder can list the mortgage, insurance, hosting bill, phone subscription, domain renewal, or SaaS account. It does not make sure those bills keep getting paid after the card or account behind them is blocked. Your family still needs to know what is urgent, who can act, and which payments need a new route before something important fails.
That is the same mistake in a friendlier wrapper: confusing "the files exist somewhere" with "the right person can use them at the right time."
"It works on my server" is not the same as "it works for my family"
Technical people often overestimate how transferable their systems are.
You know why the service exists. You know where it runs. You know what the warnings mean. You know which logs matter. You know whether "primary" in a note means a username, a mailbox, a server, or the bank account that pays the mortgage.
Your survivors inherit the output, not your mental model.
They do not need an elegant stack. They need a legible handoff.
That means they need to know what exists, what matters first, who should receive it, what is urgent, what is sentimental, what is financial, what belongs to the business, what needs legal paperwork, and what can wait.
Most DIY systems are very good at storing access. They are much weaker at delivering context.
Here are the passwords. Here is the seed phrase. Here is the encrypted drive. Here is the server.
Fine. Access matters.
But raw access is not a plan.
Handing someone a pile of credentials without context is like handing them a box of unlabeled keys during a house fire. Technically useful, maybe. Humanly terrible.
The timing problem is brutal
Digital inheritance happens at an inconvenient time. That is putting it mildly.
The people who need the information may be dealing with funeral arrangements, legal paperwork, bank forms, tax questions, family conflict, business continuity, grief, and a dozen small administrative failures at once.
That is not when they should be discovering that your release process depends on:
- a private Git repository
- an expired domain
- a mail server with poor deliverability
- a hardware token nobody can find
- a home server behind a router they do not understand
- a passphrase you mentioned once
- an encrypted backup they have never restored
The question is not whether a clever person can make that work.
Of course they can.
The question is whether your least technical trusted person can make it work under stress, without you, after months or years of quiet entropy.
That is the real test.
Self-hosting solves one trust problem and creates another
The strongest argument for self-hosting is trust.
You do not want a random SaaS provider reading your files, holding your seed phrase, or becoming a single point of failure for your family's access to important material. That objection is valid. Any service in this category has to take it seriously.
But self-hosting does not remove trust. It moves it.
Now your family has to trust that your server is still alive. They have to trust that your notes are current. They have to trust that your backup procedure was tested. They have to trust that the DNS, billing, certificates, mail delivery, and trigger logic still work. They have to trust that they can understand the system well enough to use it when it matters.
That is not zero trust. It is hidden trust.
At least with a dedicated continuity service, the operational burden is explicit. The service has to keep the check-ins running, verify contacts, handle release logic, maintain delivery paths, and keep the recipient experience usable for people who are not system administrators.
With Trustbourne, the files are encrypted before they leave your device. The service is not supposed to know what is in your vault. The point is not "trust us with your secrets." The point is to separate secure storage from dependable release and human handoff.
That distinction matters.
A dead man's switch is not just a trigger
Many self-hosted dead man's switch projects focus on the trigger.
Did the user check in? Did the timeout expire? Should the message be sent?
That is necessary, but it is not the whole product.
The harder questions come after the trigger:
- Who receives what?
- How was that person verified?
- What exactly should they do first?
- How much context do they need?
- What should stay private?
- What should go to a spouse, a child, a business partner, or an executor?
- What happens if one contact is unreachable?
- What happens if people give conflicting signals?
- How long should released access remain open?
Those are not glamorous questions. They are the boring parts that decide whether the system is useful.
A dead man's switch that releases a file is a mechanism. A digital estate plan needs a handoff.
When self-hosting can make sense
There are cases where a self-hosted setup is reasonable.
If your recipients are technical, your estate is simple, the data is not time-sensitive, and the system is tested regularly by someone other than you, self-hosting can be a valid layer.
It can also work as a partial backup. A printed inventory. An encrypted archive. A password manager emergency contact. A written document in a safe. All of these are better than silence.
The mistake is treating partial coverage as a complete solution.
Digital estates are rarely one thing. They are accounts, devices, subscriptions, domains, photos, wallets, recovery codes, insurance documents, tax records, business systems, cloud storage, family instructions, and private messages sitting across different platforms and jurisdictions.
No single tool solves all of that.
But the tool you rely on for release should not depend on the unavailable person remaining available.
Ask the ugly question
Look at your current plan and ask one simple question:
Would this still work if I disappeared for six months and nobody touched it?
Not "would the code still run today."
Not "does the Google Drive folder still exist."
Not "could I explain the system if someone asked."
Would it still work after invoices, certificates, DNS, cloud permissions, devices, passwords, app updates, family stress, and human confusion have had time to do what they always do?
If the honest answer is "mostly", you have work to do.
A good digital estate plan needs more than control. It needs release logic, verified contacts, current information, understandable instructions, and a delivery experience that works for people who are tired, grieving, and not especially interested in debugging your infrastructure.
That is the standard.
The point is not to build the cleverest system.
The point is to leave behind one that still works.