My own operation, built so it never depends on me remembering

Most businesses run on systems nobody fully understands, held together by the one person who really understands how it fits together. This is the work I do for other people. So I hold my own operation to the same standard.

Everything I depend on personally, my notes, my calendar, my automations, runs on one rented Linux box. The whole machine is written down as code: not “a server I set up once,” but a recipe that can rebuild the entire thing from a blank box, in order, from nothing. The box itself is beside the point. What matters is that nothing important lives only in my head, or only on a disk that could die.

The easy version of this is a mess. Home-grown systems rot into something only the person who built them can touch, which is exactly the fragility I warn clients about. Staying out of that trap took discipline, and three rules a non-technical owner can hold onto:

• If it isn’t written down as a repeatable step, it isn’t done.
• Prove it survives a reboot and a full rebuild, not just “it works right now.”
• Every risky change has to be reversible.

Those rules sound obvious. Here’s what earned them.

• A service died quietly for nine days. A weekly job that clears out old files to free up space was also, it turned out, deleting one of my tools between runs. It worked for a couple of days, got swept up in the next cleanup, and stopped. I didn’t notice for over a week. Every business knows this failure: the thing that works for a few days, then quietly stops on some weekly rhythm nobody connected to it. The fix wasn’t to be more careful. It was a check that notices the tool is missing and rebuilds it on its own.
• It worked until the power went out. One low-level setting worked perfectly when I applied it by hand, but I’d written it in the one place the system doesn’t re-read when it restarts. The first real reboot took the whole thing down. That is the entire case for “test the rebuild, not just today,” learned the hard way.
• A backup that was saving a third of what I thought. A single missing pair of quotes in one line of a settings file meant my backups were quietly keeping one of three databases and dropping the other two. I only caught it because I test restores instead of trusting a green checkmark. A backup you have never restored isn’t a backup. It’s a hope.
• I built something, then tore it out. I’d built the system around one ambitious piece, hit a wall that made it unreliable, and made the call to rip it out and go a simpler, sturdier way. Because everything is code and every change is reversible, I didn’t have to delete the work in a panic. I parked it, kept the recipe, and reclaimed the space with one switch. Being able to change course cleanly is something you build in on purpose, not something you hope for when the time comes.

The result is undramatic, which is the point. A dozen services on one modest box. When I re-run the recipe, it reports back that there is nothing to change, which is the proof it is genuinely reproducible and hasn’t quietly drifted from what’s written down. Restores actually restore. If I disappeared tomorrow, someone could take the recipe and stand the whole thing back up, because the knowledge is in the system, not trapped in me.

It’s the same discipline I bring to other people’s systems, practiced on the one I control completely.