Introduction

I love self-hosting things, and I have for decades. I use to host my own email server, web server, git repository, file sync platform, media server, etc. All of these things were becoming crucial to my digital life. That all came to an abrupt halt when my wife asked a simple question.

What will happen to me if you were to die? I can’t manage these things, what would I do?

I love my wife, way more than my servers, despite what my high school friends thought. I didn’t have an answer for her. I stopped hosting things. I started using paid for services that include support, but also have less than clear privacy policies or even nefarious ones. For years I’ve only hosted things on my various computers that weren’t crucial, they were just toys. I handed over my independence, and in some cases privacy, for the promise of longevity. But we all know longevity is often just a facade. I’m looking at you Google.

Well, over the years I’ve found the answer. I found what I need to take up the charge for bringing my digital life back under my control.

“Just call Best Buy and have one of their guys fix it the server if it breaks.”

Oh that would be such a bad idea! *shivers*.

==The actual solution is documentation.==

Thoughts

• Running a home lab is like homesteading, minus the weeding, the planting, the harvesting, the preserving. Just try to find someone to milk your your goat so you can go on vacation.
• In an “apocalypse” type situation of mass destruction, we’ll need two things to survive technologically. Good backups (stored in a fire safe location) and documentation.
• The article should focus on how to write good documentation
  • Capture all of the steps quickly
  • Figure out a good narrative flow
  • Flesh out the details
  • Outline the starting conditions so everyone is on the same page
  • Assume the reader of said documentation is novice in the field in which you’re document lives
    • Provide highlighted key points for people who know what they’re doing can find the key details quickly without having to read the entire doc
  • Once you’ve documented success, trash what you just built (not the documentation) and start over but following your documentation
  • Provide examples and/or diagrams to covey what should be expected at key moments
  • Clarity is key, it’s better to over communicate an idea than to assume the reader knows a “the fundamentals”. If you’re making an assumption, the communicate that to set the right expectations.
  • Understand your primary audience, and guess at what could be the secondary audience
    • The primary audience is often you and your peers. But who else may read it? Who else may want to follow your instructions, or at least understand the steps to you went through to get to the end result.
• Documentation should be evergreen and stored in open formats that can be easily read.