Disaster Recovery When You Self-Host

The honest objection to self-hosting is "what happens when the box dies," and the honest answer is: you rebuild it from a script and a backup in under an hour, on purpose, because you rehearsed it. Disaster recovery is not a reason to stay on managed cloud. It is a discipline you own instead of a promise you hope someone else keeps. Here is the recovery plan I run across a fleet, and why owned recovery is often faster than waiting on a provider's support queue.

The whole plan rests on one design choice: make the server disposable. If the machine holds nothing that is not either scripted or backed up, losing it is an inconvenience, not a catastrophe.

Design so a dead box is not a dead business

Disaster recovery starts long before the disaster, in how you set the box up. The goal is that no single machine holds anything irreplaceable.

That means the operating system and installed software come from a setup script, so rebuilding the environment is running the script on a fresh box, minutes of work. It means the state that matters, databases and user files, is backed up off the box on a schedule, encrypted, to a different provider. And it means your deploy is automated, so getting the app back on a rebuilt box is a git push, not a manual reassembly. When all three are true, the box is cattle, not a pet, and that is the mindset behind the deploy you actually control.

How to actually rebuild a dead VPS

Walk the steps, because a plan you cannot execute under pressure is not a plan.

Provision a fresh VPS. Run your setup script to install the runtime, the proxy, and the dependencies. Pull the latest off-site backup and restore the database and files. Deploy the app through your normal pipeline. Point DNS at the new box, or if you kept a spare IP or a proxy in front, flip the target. The app is back. Because every step is scripted or routine, this is a checklist you follow, not a puzzle you solve at three in the morning. The migration muscle is the same one I built in migrate off managed cloud without downtime.

The reason it goes fast is that you are not recovering a unique snowflake. You are rebuilding a known configuration from known ingredients.

Know your real recovery window

Here is the number that actually matters and that most people never measure: how long, start to finish, does the rebuild take. That is your recovery time, and you should know it before an outage tells you.

Find it by rehearsing. Once in a while, actually stand up a throwaway box, run the script, restore the backup, and time it. The first time I did this I found the restore was the slow part and tuned it. Now the whole rebuild is well under an hour, and I trust that number because I measured it, not because I hoped. Rehearsing the restore is the same discipline I insisted on in own your backups when you self-host, and it is what turns disaster recovery from a fear into a routine.

Is this really safer than managed cloud

Fair to ask, and the answer is more nuanced than "managed is safer." When a managed platform has an outage, you wait. You cannot rebuild, you cannot escalate faster than their queue, and you have no control over the fix or the timeline. Your recovery is entirely in someone else's hands, and you have no idea what your real recovery window is because you were never allowed to test it.

Owned recovery puts the timeline in your hands. A dead box, you can rebuild right now. A regional problem, you can rebuild in another region right now. You are not faster than a healthy managed platform, but you are far more in control when things go wrong, and control is what disaster recovery is actually about. This is the reliability question I worked through honestly in is self-hosting reliable enough.

Build recovery into the platform, not the panic

The mistake is treating disaster recovery as something you will figure out when disaster strikes. By then it is too late to design for it. Build it in from the start: scripted setup, off-site tested backups, automated deploys, a rehearsed rebuild. Then a lost box is a bad hour, not a lost company.

I built this recovery flow into my hosting stack, HostSSH, so every app on the fleet is recoverable the same way: rebuild the box, restore the state, redeploy, flip DNS. One pattern, rehearsed, owned. Self-hosting does not mean you are alone when things break. It means the recovery plan is yours, you have run it, and you know exactly how long it takes. That is more than most managed customers can say about the platform they are trusting with everything.