Selfhosted

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

README.md

Dokuwiki

https://wiki.gardiol.org/

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

• 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

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.

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

I use Guix

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.

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

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.

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

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

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

If you have a mix of different systems both on-prem and cloud, and tie them together in various ways using VPNs, mesh or otherwise, create a graph using something like Excalidraw to give yourself a refresher on how everything connects. You want machines, hostnames, IPs, ports, and a list of services. You don’t have to be fancy by creating visual representations of each service, just a bulleted list. You only really have to update this when adding or removing compute.

If you’re running services on lots of different nodes, a spreadsheet that just maps services to whatever URL you use access them, to whichever backend server is running them. This takes minimum effort and gets you 90% of the way there.

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

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.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:

7 acronyms in this thread; the most compressed thread commented on today has 17 acronyms.

[Thread #207 for this comm, first seen 2nd Apr 2026, 12:40] [FAQ] [Full list] [Contact] [Source code]