So I want to get back into self hosting, but every time I have stopped is because I have lack of documentation to fix things that break. So I pose a question, how do you all go about keeping your setup documented? What programs do you use?
I have leaning towards open source software, so things like OneNote, or anything Microsoft are out of the question.
Edit: I didn’t want to add another post and annoy people, but had another inquiry:
What ReverseProxy do you use? I plan to run a bunch of services from docker, and would like to be able to reserve an IP:Port to something like service.mylocaldomain.lan
I already have Unbound setup on my PiHole, so I have the ability to set DNS records internally.
Bonus points if whatever ReverseProxy setup can accomplish SSL cert automation.
I use markdown text files which are synced to my nextcloud instance.
This is somewhat tangential to your post, but I think using infrastructure as code and declarative technologies is great for reliability because you aren’t just running a bunch of commands until something works, you have the code which tells you exactly how things are set up, and you can version control it to roll back to a working state. The code itself can be a form of documentation in that case.
I think I am going down the docker compose route. When I started using docker, I didn’t use compose, however, now I plan to.
Though, Ansible has been on my list of things to learn, as well as nixOS.
Another suggestion for you, I highly recommend specifying a version for the docker image you are using for a container, in the compose file. For example, nextcloud:29.0.1. If you just use :latest, it will pull a new version whenever you redeploy which you may not have tested against your setup, and the version upgrade may even be irreversible, as in the case of nextcloud. This will give you a lot more control over your setup. Just don’t forget to update images at reasonable intervals.
I think Traefik is going to be what I investigate using. However the last time I tried, I was a little lost. I will have to comb over the documentation better this time.
Traefik is powerful and versatile but has a steep learning curve. It also uses code to control its configuration which is a bonus for reliability and documentation as discussed elsewhere ITT. Nginx proxy manager is much simpler and easier to use, may be a good one to get started with, but lacks the advantages of traefik described above. Nginx proxy manager does support SSL cert automation.
I used NGINX Proxy Manager for a while, then had some issues that ultimately killed my homelab setup, so not sure that I want to go down that route again, or if I want to investigate Caddy, Traefik, or another.
Yeah, I could never get NPM to work right on my system either. I use the NGINX Docker image and set up my certs manually.
If I were to do it all over again today, I would probably go with Caddy since it now has a bunch of that stuff built in with automatic HTTPS by default and the basic reverse proxy setup is literally 2 lines of code.
I use BookStack and with Node Red I export to PDF the books as soon as pages get updated, so if everything goes feet up, I have all the documentation in PDFs (locally and automatically uploaded to a free DropBox account, still done with Node Red).
Docker and docker-compose are nice because every service you want to run follows the same basic pattern. You don’t need much documentation beyond the project docs and the compose files themselves
Edit: caddyserver can do automatic certs, even behind a firewall if you set up the api call method. Varies by registrar
Dokuwiki (dokuwiki.org) is my usual go-to. It’s really simple and stores entries in markdown files so you can get at them as plain text files in a pinch. Here’s a life lesson: don’t host your documentation in the machine you’re going to be breaking! Learned that the hard way once or twice.
For reverse proxies, I’m a fan of HAProxy. It uses pretty straightforward config files and is incredibly robust.
Right now, I’m using Obsidian. I think I’d like to transition to keeping docs in a wiki, but I worry that it’s part of the self-hosted infrastructure. In other words, if the wiki’s down, I no longer have the docs that I need to repair the wiki.
I have looked at Obsidian, it looks nice, but the closed source part is why I can’t personally use it. Though, from discussions I have seen Logseq be thrown out when talking about similar software.
The wiki idea is a good one. The way to handle that is to have the wiki backed up incrementally.
I run a k3s cluster for selfhosted apps and keep all the configuration and docs in a git repo. That way I have history of changes and can rollback if needed. In that repo I have a docs folder with markdown documents about common operations and runbooks.
There are other ways to do this, but I like keeping docs next to the code and config so I can update them all at the same time. Deployed several wikis in the past but always forget to update them when I change things.
It simply acts as a server that you can clone with any git client and the coolest part is that you use git commits to create repositories and manage users as well. Very very or no maintenance at all. I’ve been using it personally for years but also saw it being used at some large companies because it simply gets the job done and doesn’t bother anyone.
I have an Ansible playbook that I use to setup everything and all troubleshooting steps I ever had to take to fix something get written down in an Obsidian.md vault.
I’m also using ansible everywhere in my home / private infra and lab. Occasionally I get slightly annoyed that I have to open an inventory file or a role var to find something. But in general I’m so grateful that there is one place to find this information, and the same is used to set up everything from scratch.
Is it extra work to write the roles and playbooks? Yes. Does it solve the documentation and automation problem completely? Absolutely. 10/10 would recommend. And for the record, most things I host run on containers, but the volumes and permission management alone make it worth your time.
I’ve been using YunoHost for some time. Cosmos seems good, too. Both do most of the stuff for you and should come with documentation. I think that’s the way to go if you can’t set it all up yourself, or lack time to maintain it.
I’ve also used Docker containers and plain Debian. I use NGinx as a reverse proxy.
I document things in text files (markdown). At some point it’d like to upload them with something like mkdocs or to a wiki. But since it’s just me, having them just sitting in a directory on my laptop is fine.
Use something that’s super accessible so you’ll actually use it. I often just dump random thoughts or commands I executed into the textfiles and I have my text editor open all the time anyways. And then on the server I eiter use Ctrl+R and search through the shell history, or search in my documents. Doesn’t need to be fancy, grep -rni "keyword" does it for me.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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).
I use obsidian for my notes/wiki. I use the git plugin to backup/sync my notes. I self-host forgejo as my gut server. Works great!
Caddy is my favorite reverse-proxy. The setup is just a config file.
I use markdown text files which are synced to my nextcloud instance.
This is somewhat tangential to your post, but I think using infrastructure as code and declarative technologies is great for reliability because you aren’t just running a bunch of commands until something works, you have the code which tells you exactly how things are set up, and you can version control it to roll back to a working state. The code itself can be a form of documentation in that case.
I think I need to utilize this strategy because I get lazy and don’t update external documentation.
Some examples of technologies which follow that paradigm are docker compose, ansible, nixOS and terraform. But it all depends on your workflow.
I think I am going down the docker compose route. When I started using docker, I didn’t use compose, however, now I plan to. Though, Ansible has been on my list of things to learn, as well as nixOS.
Another suggestion for you, I highly recommend specifying a version for the docker image you are using for a container, in the compose file. For example, nextcloud:29.0.1. If you just use :latest, it will pull a new version whenever you redeploy which you may not have tested against your setup, and the version upgrade may even be irreversible, as in the case of nextcloud. This will give you a lot more control over your setup. Just don’t forget to update images at reasonable intervals.
That is good advice, and honestly never really occurred to me to set specific versions for containers.
Traefik for reverse proxy. Tag your container with the route and let traefik take over.
I think Traefik is going to be what I investigate using. However the last time I tried, I was a little lost. I will have to comb over the documentation better this time.
Traefik is powerful and versatile but has a steep learning curve. It also uses code to control its configuration which is a bonus for reliability and documentation as discussed elsewhere ITT. Nginx proxy manager is much simpler and easier to use, may be a good one to get started with, but lacks the advantages of traefik described above. Nginx proxy manager does support SSL cert automation.
Jim’s garage has some videos on it.
I’m adding documentation about what I do in Joplin and I’m using Nextcloud to keep it synced.
For reverse proxy I use Nginx Proxy Manager for its simplicity. I really don’t need anything more fancy… https://nginxproxymanager.com/
You could try Logseq, it’s like Obsidian but open source. I use Obsidian for most notes and I also have a personal wiki built with Otterwiki.
I use NGINX for my reverse proxy, you could check out NGINX Proxy Manager which uses Certbot to automate the SSL certificates.
I’ve heard a lot of people also like Caddy and Traefik. Can’t remember which is easier to use, maybe Caddy.
I will likely dabble with Logseq.
I used NGINX Proxy Manager for a while, then had some issues that ultimately killed my homelab setup, so not sure that I want to go down that route again, or if I want to investigate Caddy, Traefik, or another.
Yeah, I could never get NPM to work right on my system either. I use the NGINX Docker image and set up my certs manually.
If I were to do it all over again today, I would probably go with Caddy since it now has a bunch of that stuff built in with automatic HTTPS by default and the basic reverse proxy setup is literally 2 lines of code.
I use BookStack and with Node Red I export to PDF the books as soon as pages get updated, so if everything goes feet up, I have all the documentation in PDFs (locally and automatically uploaded to a free DropBox account, still done with Node Red).
I may have to check out BookStack. I dig the looks of it.
Docker and docker-compose are nice because every service you want to run follows the same basic pattern. You don’t need much documentation beyond the project docs and the compose files themselves
Edit: caddyserver can do automatic certs, even behind a firewall if you set up the api call method. Varies by registrar
Dokuwiki (dokuwiki.org) is my usual go-to. It’s really simple and stores entries in markdown files so you can get at them as plain text files in a pinch. Here’s a life lesson: don’t host your documentation in the machine you’re going to be breaking! Learned that the hard way once or twice.
For reverse proxies, I’m a fan of HAProxy. It uses pretty straightforward config files and is incredibly robust.
Right now, I’m using Obsidian. I think I’d like to transition to keeping docs in a wiki, but I worry that it’s part of the self-hosted infrastructure. In other words, if the wiki’s down, I no longer have the docs that I need to repair the wiki.
I have looked at Obsidian, it looks nice, but the closed source part is why I can’t personally use it. Though, from discussions I have seen Logseq be thrown out when talking about similar software.
The wiki idea is a good one. The way to handle that is to have the wiki backed up incrementally.
OPNSense router handles auto SSL certificate renewals, Unbound (DNS) and HA Proxy ( for reverse proxy ).
Gitea instance for all of my docker-compose configs and documentation.
Joplin server and Joplin clients for easy notes available on all my devices.
I run a k3s cluster for selfhosted apps and keep all the configuration and docs in a git repo. That way I have history of changes and can rollback if needed. In that repo I have a docs folder with markdown documents about common operations and runbooks.
There are other ways to do this, but I like keeping docs next to the code and config so I can update them all at the same time. Deployed several wikis in the past but always forget to update them when I change things.
I really should spend time familiarizing with maintaining a git repo. I’ll likely find one I can self host.
If you want a git “server” quick and low maintenance then gitolite is most likely the best choice. https://gitolite.com/gitolite/index.html
It simply acts as a server that you can clone with any git client and the coolest part is that you use git commits to create repositories and manage users as well. Very very or no maintenance at all. I’ve been using it personally for years but also saw it being used at some large companies because it simply gets the job done and doesn’t bother anyone.
I will have to check out gitolite. Thank you!
https://forgejo.org selfhosted has been good for me, FOSS fork of Gitea.
Thank you for the suggestion. The fact that it’s FOSS wins my vote. I have been trying to go all open source where possible.
I have an Ansible playbook that I use to setup everything and all troubleshooting steps I ever had to take to fix something get written down in an Obsidian.md vault.
StandardNotes for me
I’m also using ansible everywhere in my home / private infra and lab. Occasionally I get slightly annoyed that I have to open an inventory file or a role var to find something. But in general I’m so grateful that there is one place to find this information, and the same is used to set up everything from scratch.
Is it extra work to write the roles and playbooks? Yes. Does it solve the documentation and automation problem completely? Absolutely. 10/10 would recommend. And for the record, most things I host run on containers, but the volumes and permission management alone make it worth your time.
I’ve been using YunoHost for some time. Cosmos seems good, too. Both do most of the stuff for you and should come with documentation. I think that’s the way to go if you can’t set it all up yourself, or lack time to maintain it.
I’ve also used Docker containers and plain Debian. I use NGinx as a reverse proxy.
I document things in text files (markdown). At some point it’d like to upload them with something like mkdocs or to a wiki. But since it’s just me, having them just sitting in a directory on my laptop is fine.
Use something that’s super accessible so you’ll actually use it. I often just dump random thoughts or commands I executed into the textfiles and I have my text editor open all the time anyways. And then on the server I eiter use Ctrl+R and search through the shell history, or search in my documents. Doesn’t need to be fancy,
grep -rni "keyword"does it for me.