What I Self-Host | Aspirational Self Hosting Guide
34 points by tonymet
34 points by tonymet
I don't understand self-hosting Uptime Kuma. I like self-hosting as much as I can. But I stay away from self-hosting my monitoring and uptime tools. I take my services down often, by accident and on purpose. If my machine runs out of disk space or power, what happens? Are people monitoring other services? Seems like they're pinging home automation devices.
Because of this fear, I rely on cloud-hosted Grafana for metrics/logs and cloud-hosted UptimeRobot, though they're surprisingly unreliable.
I've had this idea for a while now that self-hosters should find other self-hosting friends and do an reciprocal exchange where they offer to host backups and monitoring for other self-hosters on their infra to avoid a dependency on corporate services.
Unfortunately I don't have my shit together enough to care about monitoring so I haven't actually done it, but here ya go; free idea for an enterprising self-hoster.
I've done this with a friend on the backup side. We both have hefty NASes, with TBs free, so we have a user and a share on each dedicated to the other and have a dedicated ZeroTier network between them (I use tailscale these days but TS doesn't allow a node to be connected to more than one tsnet at a time but ZT does).
B2 is so cheap that unless someone needs 6+ TB of data, self hosted solution doesn’t make financial sense.
You can run the monitoring tool on a separate server in a different location. In all of your scenarios above, your monitoring tool can tell you about it.
For example, you can self-host most of your services at home or on a rented machine, and use a tiny VPS elsewhere (in another region, and another provider if you're not self-hosting at home) exclusively for monitoring.
You may be interested to read about Low-Tech Magazine's solar-powered website. Hosted on the author's balcony window in Spain, it has a small backup battery to allow it to run through most of the night most of the year. Sometimes (especially during winter) the battery runs out, and the website is inaccessible for a few hours. The website's CSS displays the current battery level. A larger battery and solar panel would increase the uptime, but also the ecological (and monetary) cost of the website, so the author has expressly chosen to accept downtime.
In chronological order:
A common pattern is self-hosting a prober like Uptime Kuma, and configuring it to probe a dead man's switch like https://healthchecks.io/
If your monitoring goes down, healthchecks.io will alert you.
Selfhosted Uptime Kuma is mostly good at detecting if you get a service crash somewhere that you aren't immediately aware of, but do want to know happens.
Like, I have a script that needs to run every hour to contact an API service that is considered to be a moving target with no published changelogs; it can fail at any point with no apparent warning - if run successfully, it will not necessarily report output anywhere. If it fails, the server won't go down in flames, but it does require attention. I don't have constant SSH access to the server and don't have the desire to access it all the time.
Uptime Kuma lets me pipe a curl POST to an endpoint if the cronjob I use to run the service succeeds. If it receives no POST for 90 minutes (the 1 hour delay+30 minutes of execution time), I can assume the cronjob has failed or is taking an unusually long time. I can then get a notification from any of it's 50+ reporting methods.
Even just for web services, this is nice to have. Sometimes a service relies on a mounted network drive that can sporadically vanish and the entire thing goes down quietly, but again won't set the server on fire. Having Uptime Kuma just check whether or not the service is running by sending a request to the domain is a big benefit.
Most selfhosted setups I've had over the years aren't accessed all the time; I'm not constantly using navidrome for example, but I do want to know when it goes down preferably before I try to connect my phone to a friend's speakers when hanging out with them. Fully external uptime checks aren't necessary for 90% of those situations (and land outside budget I'm willing to pay for self-hosting), but it doesn't make the local one useless.
I fear my self hosting setup is heavily intertwined with tailscale, but that makes it soooo much easier to maintain and use (magicdns, service names, always accessible, etc.). I really do empathize with people not wanting to use/rely on it, but surprised to not even see it mentioned here.
Also, if someone here has experience using Headscale, I’m all ears. Always wondered if there are any huge caveats with it.
Been using headscale for couple of years. For the most part, everything has been smooth sailing. I did fuck up some config and my RPi behind cloudflare tunnel started to only be accessible from the headscale server itself, but thats on me. I haven't found the root cause yet, and maybe I won't because I have to to start from scratch on it anyway.
All in all, I'd give it a go. I'd be out of Tailscake free device number long ago, but headscale just keeps working.
The biggest annoyance with headscale is every upgrade you have to go edit the config file. The docs are fine, as long as you follow the docs you are good, but I can't think of a single release where I didn't have to add/remove or change at least 1 line in the config.
Also, to Headscale's credit, if you mess up the config(like leave in a deleted setting) it gets mad and tells you what you did wrong.
Otherwise it's been working great for a long time now.
Been using headscale for a couple of years now and it's working great (I use the NixOS module). My complain sits mostly with tailscale, which has some knobs you should turn to disable features that caught me by surprise (i.e. you have to opt out of client logging or Taildrop). My other issue is that sometimes updating a Tailscale client means you also have to now update Headscale because the client refuses/can't work with older headscale versions.
Ditto. TS docker sidecars for each of my services. This model predates tailscale "services" so I could the number down but the upside of dedicated sidecars which services can't offer is sharing that singular "machine" out to someone else's account. I do this with Plex, for instance, to give trusted friends relay-less access to my server without opening a public port for it.
Regarding hardware (and current hardware pricing), consider going used! You can find lots of used hardware on sites like Ebay that was decommissioned by companies but is still more than serviceable for home use.
For example, recently I bought a used Lenovo M720q with an i5-9500T, 32GB of DDR4 and a 256GB SSD for 270€ shipped.
I'll second this! A couple of machines that i use for self-hosting at home are stuff bought as refurbs or decomms by companies! Also, while i have not done it myself, i have heard of folks using old laptops...Because if the laptop battery still works/holds a charge, then you have instant "power backup" whenever the power goes off!
I loved this post! Always great to hear what and how folks self-hosting!
I myself have kept shifting back-and-forth the last few years between hosting stuff on rented VPS vs homelab/home machine...and lately, its only a single low-cost VPS running a Caddy reverse proxy pointed at my home machines via tailscale. While i ahve diminished the total number of services i am hosting, the rev. proxy approach has been pretty great! While i like tailscale (or maybe they're at that stage like when many people liked google years ago), but in the far off future, i'd like to move away from tailscale, and manage my VPN separate of ANY company. Still, i have to admit that tailscale is pretty rock solid; at least for my scenarios.
And, yeah, the days of self-hosting email are long gone for me....I pay a provider and use my own domain name (so if i ever tire of my current provider, my mail goes with me)...However, the one use-case where i think self-hosting one's email is for automation. That is, instead of using transactional mail providers, one can stand up an email server under a dedicated domain name, and merely use it for automated emails...Think: system notifications, reminders, daily zen quotes of the day, etc...Hell, much like the author noted about self-hosting Vikunja, that platform leverages/needs smtp server....so if one was to self-host email server, that can be used for your vikunja projects, etc. Obviously, will have to configure DNS right to ensure deliverability to your on, separate personal email...but for email use that is only for you/your family/internally, yeah that is one area where self-hosting email server is ok nowadays.
Seems like a lot of services for monitoring services! I personally noticed a large uptick in reliability on my NAS once I adopted a no-container policy (so systemd services only). I also auto-reboot nightly which might help smooth over transient state issues.