It depends on what it is. I do not have a singular documentation-platform or wiki for those things. I’m more of the keep the docs where the code is guy. I also try to keep complexity to a minimum.

All my linux server setups are done with ansible. ansible itself is pretty self-documenting, as you more or less declare the desired outcome in YAML form and ansible does the rest. This way, I do not need to remember it, but it’s easier to understand when looking it up again.

Most of my projects have a git repository, so most of what I need to know or do is documented

• in a README.md
• as pipeline-instructions inside .gitlab-ci.yml

This way, I was able to reduce complexity and unify my homelab projects.

My current homelab-state is:

• most projects are now docker-based
• most projects have a GitLab CI for automated updating to newer versions
• the CI itself is a project and all my CI-docker-based deploys use this unified pipeline-project
• most projects can be tested locally before rolling out new versions to my VMs
• some projects have a production and a staging server to test
• those which cannot be dockerized or turned into a CI are tools and don’t need that (e.g. ansible playbooks or my GitLab CI)

On what to include, I always try to think: Will I still be able to understand this without documentation if I forget about the project for 6 months and need to make a change then? If you can’t be sure, put it in writing.

If it’s just a small thing regarding not the project itself or the functionality or setup itself but rather something like I had to use this strange code-block here because of XXX, I’ll just put a comment next to the code-line or code-block in question. These comments mostly also include a link to a bug-report if I found one, so i can later check and see if it’s been fixed already.