Selfhosted

Ansible.

Infrastructure as code is the best documentation.

ADHD: functional notes in abbreviated version on fat strips of painter's tape on server case or shelf. Passwords go on page dedicated to that server or service in a little black notebook, then eventually in a password manager.

Readme file if my brain lets me, usually 3 months later after hyperfocus on troubleshooting.

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

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.

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

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

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.

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.

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.

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.

• 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 use Guix

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

Mostly just quick notes in Obsidian, if I do anything complex or 'unusual' to set something up I'll save the history that I ran.

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

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.

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.

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

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.

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.

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 use obsidian, I dont really have a self hosted setup yet but thats what I use to document desktop config and what I will use for my server when I get it running.

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 🙃