I just create a README.md file wherever I setup services with docker compose which keeps top level docs so I know how and why certain things work.

Other than that, if comments are supported inside configuration files, also document stuff in there too.

That’s been good enough for me.

The moment you think you might possibly need documentation is the moment you should seriously consider using Ansible or similar to orchestra things. Sure, it’s annoying for a single server, but it is the best form of documentation there is.

Man I’m as basic as it comes. I have a .txt file that I update with today’s date and write what I’m working on. I try to write as much as needed on what I’m working on. I write commands down and save links to reading material.

It’s not the best but it’s better than nothing.

When I set something up I write all the steps I’m doing in obsidian as I do it. The pages get tagged so they’re searchable in the future.

I use Guix

I’m actually in the middle of rebuilding my entire setup right now and one of my major goals is to actually document my processes this time.

I use Obsidian which is a Markdown editor and I have a couple plugins alongside that for QoL stuff and extra features.

I document processes, problems and fixes I encounter, list of active services alongside where/how to access them, and plans for future additions/changes.

As far as working documentation into your flow, realistically that is just a matter of discipline. It is explicitly up to you to stay on top of documentation.

Hope that helps, and good luck with your endeavor! 😁

draw.io in my nextcloud

And leantime to keep track of what I want to do with notes and such

And a mess of notes in Joplin.

I’m surprised no one else has answered mediawiki. Love my mediawiki instance.

README.md

I run Adguard Home containers (the primary auto-syncs to the secondary) and use redirect filters to assign hostnames to each of my containers. I have a “services” folder of bookmarks for each container host so I don’t have to remember each service’s port number. I use KeePassXC to track all my passwords and certificates so authentication is a breeze (someday I’ll get around to setting up an SSO solution). I also keep a .txt file with my basic network info that doesn’t always translate well to dns hostname redirects in adguard. I occassionally remember to update my hosts listed in the file. My individual config files aren’t backed up beyond my automated container backups, but so far none of my services have been that complicated I couldn’t just rebuild from scratch.

It’s not perfect, but combined with my automated backups I have barely enough to rebuild if/when my hardware fails.

I have a bare minimum of documentation as markdown files which I take care to keep in an accessible lovation, aka not on my server.

If my server does ever go down, I might really want to access the (admittedly limited) documentation for it

what you use for your documentation

Hugo (markdown) files that i host on my internal server.

how you organize it

I use basic directory structure. Top level directories are like “dev”, “home”, “general”. Self hosting is a dev/ subdir.

what information you include

Depends on how familiar i am with it and how often I’ll be referencing it. Something i know well or access often will be more high level. Things like an annual process i have documented in more detail

how you work documentation into your changes/tinkering flow

My site has an “edit this page” feature which i use to open my IDE and make the change as I’m doing things. Sometimes I’ll be lazy and just add in what i did this time and then let future me reconcile the differences 🙃

I use Obsidian with a folder for hardware and a folder for software, then an entry for each device or service. I’ve been pretty good about maintaining cross-links.
I kind of wish I used Docker Compose more, but I haven’t run into a situation where it’s been a problem yet.