That's the neat part, I don't.

The fun thing about infrastructure as code is that the terraform, ansible and k8s manifests are documentation.

I only really need to document some bootstrap things in case of emergency and maybe some "architectural" things. I use joplin for that (and many other things).

• what you use for your documentation

Markdown files

• how you organize it

What ?

• what information you include

The commands that worked and the stuff that didn't work and the links to the source of information

• how you work documentation into your changes

I write as I go. I keep it as part of a git repository when relevant

All my computers (including servers) share the same NixOS Flake. So my documentation consists of:

1. The Nix code itself
2. The commit messages for each change I make
3. Inline comments in the Nix code
4. A few readme.md files to explain the contents of certain directories

README.md

Dokuwiki

https://wiki.gardiol.org/

For me for future memory and for others who might need it

Why do you have to be like that? Drop the innocent questions and just come right out and call me a piece of shit directly.

• I use Obsidian
• Usually, what I do is write the documentation as I am engaged with the project at hand. Then clean everything up, and transfer to Obsidian.
• I include everything. I don't leave anything for my mind to wonder about. If I didn't write it down, it didn't happen.
• Date any addenda or changes (4-2-26: Firewall rules review)

I used to try and do it all in obsidian but I'd forget a lot. Now I use nix and it's all done for me basically

NixOS because it's declarative kind of does it all for me.

The .nix files serve as their own documentation and if I need to do anything outside them I add a comment to the .nix file.

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.

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 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

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.

At work, since I’m the sole IT, I’ve been putting everything into MkDocs and it’s been working out great for the team. Only complaint is that I can’t seem to figure out how to update anything without just relaunching the Docker container every time. They mention that you can live reload, but not how.

I use Guix

I'm just rewriting everything in Ansible and I think is worth the effort, it's self-documented and as an added bonus I won't have to keep backups of the whole VMs, just the ZFS pool with the data/databases.

Notesnook notebook with whatever info I need to be able to administrate the system. e.g. what different ports are used for and why the firewall policies are what they are, sometimes write-ups after a troubleshooting session, etc.

The Notesnook instance is self-hosted too, but if the server goes down, the notebook will still be available locally.

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.

Use declarative systems and software, where the configurations files themselves are the documentation. For example, I use Guix and Podman. The entire OS is described in a Scheme file and all the services are described in a YAML file. I just need those two files to get an overview of the entire setup.

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! 😁

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.

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

Bookstack in a docker container. You can export pages with revision numbers and dates. I print out the emergency stuff and keep it in a binder. https://www.bookstackapp.com/ I've been using it at work for like a decade now. No apps or anything though, just a decent web interface.

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.

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.

Short: don't do anything manually, throw it into a ansible playbook. Save it somewhere.

err . i don't really. well I do a bit. the obvious one is config-as-documentation: docker compose mainly. I'm in the middle from migrating from storing them in portainer's internal store to using git (and dockhand), which should improve their role as documentation with the addition of vcs.

in addition I have a handful of markdown notes in my obsidian vault to track a few things. there's some general terminal stuff command references, which aren't strictly for the server. i have a list off all my hard drives, including their SN,PN,Partition UUID and label (this is their partition/volume label as well an actual physical label on them. It makes moving between operations on my host machine, omv VM and physical drive easy. its a maddening combination of using three or more command ouputs to map a drive between whatever info is available in proxmox, a vm or physically otherwise!

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.