A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
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 just think I do that, but absolutely don't.
write-only memory.
no read, only write!
Yeah I also use config-as-code along with wiki but I used to remember things 10 years ago when the setup was simpler and the brain was newer. 😅
I read the title and this was literally the first thing that popped in my head
I'm here to serve.
I use Guix
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.
That's the neat part, I don't.
"I don't need to, I have it stored all in my head."
Famous last words.
Documentation is for onboarding other people. Why on earth would I need to onboard other people to something self-hosted?
Sometimes future me has the memory of a goldfish, and I fear that, for future me, the online sources that guided me before won't be there for me anymore
It's not like anyone needs to support it when I'm gone.
"I can remember that" is my cue to write it down, because I won't.
The theory is I use Docmost. The reality is I don’t, and I hope my backups are solid.
I have an obsidian document where I write changes I want to do in the future that I never look at; does that count?
I just found my todo list and half of it is irrelevant and half of it is done.
I even had a work todo list for my old job lol.
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 second Obsidianmd.
Even before adding community plugins, the search, organization, and the ability to easily link to other documents/screenshots make documentation so easy for me
README.md
README_I_AAM_VERY_IMPORTANT.md
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).
That's the direction I'm moving my lab in. Plus a bit of supplemental markdown to keep track of which guides I'm referencing (and which parts can be ignored because I baked it into the terrafom). It's really nice to know that as long as I tweak the terraform for changes, I don't have to worry about forgetting what I changed.
- 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
Had to scroll down this far just to get to markdown files. Although I write with a bit of a delay. Once I get something working. Then I document what worked and what didn't. Alternative methods and issues I had with the alternatives.
I'm surprised no one else has answered mediawiki. Love my mediawiki instance.
All my computers (including servers) share the same NixOS Flake. So my documentation consists of:
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
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.
Using Mediawiki here.
I have obsidian and tried using it, but my personal workflow for my homelab just doesn't...work with it? Idk, it's just easier to throw it into a private wiki.
I still use obsidian but for personal life stuff.
Look's great, thanks
BTW, this gent's wiki is worth a bookmark. Stumbled on it before I knew the originator.
Thanks you, it means a lot. Just to be clear for whomever didn't go there: there is zero monetization, no ads, no profiling.
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 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 was just introduced to NetBox and it's really intriguing. It does look complicated but once it is setup it seems to work very well at integrating data from a spreadsheet into it and then automatically documenting changes and such. It's open source as well.
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.
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 🙃