Advice for Self Hosters

I just finished upgrading my final self hosted service to be available over IPv6. This was a staged upgrade handled over several months. All of the upgrades went smoothly. I attribute this success to years of stupidity. I've made a number of mistakes over the years. Some of them cost me a great deal of time and grief. But they all taught me valuable lessons. This post is a collection of some of those lessons. If You're interested in self hosting, I hope this advice proves valuable to you.

1. Automate everything.

This is probably the most important lesson I've learned over the years. The reason my server upgrades went so well is because all of my builds are automated. This allows me to treat all of my servers like cattle. When the time is right, I slaughter them. The time is usually right when there's a major Fedora release. This is because most of my services run on Fedora Server at the moment. When a new major version is released, I don't do a dnf system-upgrade. Instead I nuke the virtual machine that hosts my service, create a new one, and install everything from scratch.

My builds weren't always automated. I manually built all of my servers for many years. Because of how arduous building some of my servers was, I would sometimes let the host operating system get woefully out of date. Eventually they would get to a point where I had to rebuild them. Sometimes this was due to a hardware failure. Sometimes it was due to a security vulnerability in my stack. What I discovered is that I didn't remember all of the ins and outs of building the server. The task would take much longer because I had to rediscover everything I forgot. That isn't a problem now that everything is automated.

This advice doesn't apply only to building servers. Your backups should be automated. If your backups aren't automated, they won't get done. TLS certificate renewals should also be automated, especially now that certificate lifetimes are becoming shorter and shorter. Everything should be automated.

You'll hear a lot of advice about the best automation tools. Each automation tool has ups and downs. I settled on Ansible for automating my system builds. It's a good tool in general but configurations are done in YAML and YAML sucks. NixOS is an option more people seem to be adopting. The upside is the entire system build is declared in a configuration file. The downside is you have to use NixOS (I don't think NixOS is bad, I just want to note that you can't use the NixOS method with other operating systems). Don't let yourself succumb to decision paralysis. Look up a few automation tools, pick one that looks good, and learn it. Even shell scripts are better than nothing.

2. Consider maintenance.

Every self hosted service will require maintenance. How easy or hard the maintenance is will determine how often it gets done. I'll use TLS certificate management as an example. TLS certificates have a lifetime. That lifetime is becoming shorter and shorter:

• From today until March 15, 2026, the maximum lifetime for a TLS certificate is 398 days.
• As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days.
• As of March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.
• As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.

Certificate management used to be much more complicated than today. You had to create an account with a certificate authority. Once you had an account, you had to verify your identity, usually by providing a picture of your government ID. Then you could get a certificate for your domains that was good for one to two years. The maintenance wasn't insignificant, but you only had to go through the process every one or two years. However, it was often easier to create your own certificate authorities if your self hosted services that were only available on your local network or were only used by devices you controlled.

Now the maintenance burden is changing. As certificate lifetimes shrink, it'll become infeasible to manually manage your TLS certificates. If automating your certificate maintenance isn't possible, which it might not be for a service only available on your local network, you can still provide a secure connection to it using something like WireGuard. WireGuard keys have no prescribed lifetime. Depending on your situation, it might be easier to make your self hosted service only available over a WireGuard connection so you can avoid the hassle of dealing with certificates.

3. Simple is usually better.

The best illustration of this rule is my post about Caddy. I migrated my reverse proxy server (and since then all of my HTTP servers) from Nginx to Caddy. The reason for this migration was that Caddy is much simpler to configure than Nginx. What can easily require two dozen lines of configuration in Nginx can often be done in a single line in Caddy.

My migration from OpenVPN to WireGuard was done for similar reasons. OpenVPN is a very flexible protocol. Unfortunately that flexibility comes with significant complexity and that complexity hides a lot of footguns. WireGuard on the other hand is opinionated. There's very little flexibility. That lack of flexibility means configuring a WireGuard interface is simple and there are no obvious footguns.

Another example is my self hosted Nextcloud instance. My original Nextcloud instance was built (using Ansible, of course) by setting up the database backend, installing all of the required packages, copying the Nextcloud PHP files to the web root, and bringing everything up with systemd services. Then the Nextcloud team released their All-in-One Docker container. Installing the All-in-One Docker container is much easier than building everything from scratch. I use it now because it's simple to install and maintain (it can do automatic updates).

I'll point to this blog as my final example. For many years this was a WordPress blog. Last year I finally migrated it to a static website. I can't overstate how much simpler this blog is to maintain. I no longer need a database or PHP-FPM. I don't have to worry about the seemingly endless security issues that WordPress suffers. Best of all is I don't have to worry about a WordPress update enshitifying writing and editing posts (Gutenberg was such a terrible experience that I had a WordPress plugin to bring back the old editor). Now I can write my posts with any text editor I please.

I won't go so far as to say that the simpler option is always better. But preferring the simpler option is a sane default.

4. Practice your recovery plan.

I noted that you should have automated backups in my first suggestion. But a backup isn't useful if you can't restore the data. The only thing harder than getting people to backup their data is getting them to test restoring it.

Since I automate (see how important my first suggestion is) building my systems and I rebuild them every time there's a major Fedora release, I have an opportunity to test my recovery plan roughly every six months (Fedora releases a new major version about twice a year). Part of my automated builds involves pulling data from my hot backup system. I know my restores work because I test them frequently. Get in the habit of testing yours. It's much better to know how to restore backups when you don't need them than to find out you can't restore them when you do need them.

5. Have fun.

I'll level with you. If playing with operating systems, building servers, and learning networking doesn't sound fun to you, self hosting isn't for you. If you're not having fun when things are working, you definitely won't have fun when things aren't working.

Self hosting is part research, part engineering, and part detective work. The research is the easy part. You think of a service you need, find what options are ability that fulfill that need, read the documentation (if there is no documentation, don't use it), and end up with an idea of how well the service will fill your need and how easy it will be to setup and maintain. Then comes building the service. This is where the engineering part comes in. If you listen to my advice, you'll automated the building process. But even manually building a service will require engineering effort. Then eventually something will go wrong. This is where the detective part comes in. What went wrong? What are the likely causes? How can those causes be address? Is it DNS? It can't be DNS. It was DNS!

Life is too for voluntary suffering. If self hosting isn't a fun hobby to you, go find a hobby you'll enjoy instead.