I don’t, and I know that I’m fucked one day.

I am fortunate enough to only manage a homelab and not an enterprise sized network. So I don’t document anything just like at work.

I download the YouTube tutorials I followed, upload them to my UAT Jellyfin server, and then when my server is having issues I can’t get to the videos!

A flawless system really

Lol.

I build my infrastructure with the terraform, Ansible and helm charts. The code is it’s own documentation as well as comments in that code explaining why I’ve done things if it’s not obvious.

Here’s my approach to documentation. It’s about habits as much as it’s about actually writing anything down:

1. Never setup anything important via naked terminal commands that you will forget you did

2. Always wrap important commands in some kind of “setup-xyz.sh” script and then run that script to see if your install worked.

3. If you need to make a change to your service, ensure you update your script and so it can be re-run without braking anything

Get into the habit of this and you are documenting as you go

I use the notes sections in proxmox preeettty heavily. Lots of links to the helper scripts, youtube videos and other resources i used to get er’ goin’.

In the near future I’m really hoping I can set up Netbox to help me document the network and equipment I’m putting in my homelab. a nice thing is that I went through a divorce a while ago and I’m getting to start from scratch. You’d be surprised at just how much you’ve learned since starting to self host and I think there’s this sunk cost fallacy that gets a lot of us to keep going with what we’ve got already set up because we’ve “already put so much work into it” and the concern of what we might lose by scrapping it and starting over.

Also, not what you asked… but if you’re still relatively new with proxmox you should check out the ProxmoxVE helper scripts. Lots of good automated scripts from doing a post-install to setting up various LXC containers and VM’s

95% of my homelab lives on a single server, and everything I do is within containers. So, my documentation is just keeping all my compose files in a git repo and writing in comments when necessary. It’s fairly self-documenting, and I haven’t found the need to break out of just using containers for everything, besides a couple things like setting up mergerfs or cockpit, but that’s all plug and play nowadays with stuff like https://projectucore.io/

Of course, I don’t have any other things set up in my physical layout or network stack… but all that stuff would probably just go into an entry in my notes (obsidian/wiki.vim).

I generally just make notes in Obsidian, mostly about switch ports, VLANs, IP assignments and that kind of thing.

Also try to save snippets of commands or config edits I needed to get something obtuse working in case I need to do it again later.

I just set up everything via ansible and comment everything religiously, I’ve gotten to the point where I have playbooks for my laptop and desktop so if I have do do a clean install I just have to run the playbook and everything is set up and installed to my liking

It’s annoying to go to my playbook to make changes and rerun it every time I want to install or remove anything from my daily PCs, but it pays off when I migrate computers or for some reason have to do a clean install

And for high level stuff and things not in ansible I keep a tiddlywiki since no matter how catastrophic the failure of my systems I can always find a way to access an HTML file for my own reference

Every time I set up anything, I do one of two things:

• If it’s container based, it gets a commented docker compose file in my custom orchestration

• If it’s on a host system, the changes are scripted and commented in a setup script, which are run on new machines. If the acrit is specific to one machine, it is configured as such

I find in-setup docs to be best for a home lab, plus if I have to replace hardware, it’s fast.

Fun fact, I do it for laptops and desktops, too.

It’s really a wild growth over the years. My current approach is twofold. Netbox to manage devices/VMs and associated info with service deployments using Ansible. You can use the info from Netbox as an Ansible inventory directly.

Previously I tried network diagrams (too low detail) and spreadsheets (terrible to modify) to document machines. And for serviced I’d have an install page on my wiki (apologies, the codeblocks are somewhat broken atm)

The whole deployment is done via ansible, so the ansible source is my documentation.

I keep a very rudimentary README.md with some basic info on the services I run. I should probably set up a personal wiki to keep track of everything better

Perhaps more importantly, I also maintain a document with all the scheduled tasks that run, including what it is, how it’s defined, when it runs, and what device runs it. Really helpful for making sure cron jobs don’t run during a backup script or something

I’m curious how everyone documents their core/critical configs to allow the non-technical in our homes work with it if needed. For instance if I’m on work travel and the Pi-hole goes down for whatever reason my wife wouldn’t be able to use pretty much anything online. I can remote in and fix it but that could be hours/a day or two later. Same then for the proxmox stack that everything runs on.

Along the same lines, how are folks documenting for EOL? It may not be a happy thought but we are all going to go someday, so what is your plan and how have you ensured loved ones can access/save important data?