Wow!

Setting up this site was a lot more involved than I expected, but I’m glad I made the ultimate decision to set up a server from scratch rather than subscribing to a shared hosting service.

My main concern with using a plain VPS was that the setup would be trivially simple and result in a very middling, unopinionated installation while the controls provided by shared hosting could be better adapted to the specific needs of operating a small site, like access to proprietary control panels or web servers with easy to use default configurations that make sense for my very common use case. Shared hosting is more of a finished product than a general web server, so it makes sense to be more streamlined and suited for that task. I wanted to earn my way to the same destination on merit and minus the closed source code if possible. I believe I achieved that goal yesterday evening.

With that said, I can’t completely discount the benefits of shared hosting. This page was down for 2 days while I meticulously rebuilt the server from a fresh image–something that wouldn’t have happened had I gone with the shared hosting route. But, I learned so much for having done so! For example, I learned that a static site generator (Jekyll) doesn’t meet my needs because it’s not very effective in quickly managing media-rich content nor does it support comments without including some other service, most of which are proprietary discussion services like Discus that don’t respect user data privacy. I decided that supporting discussions and the ability to quickly include multiple images and videos in my posts is very important to me, and when it comes to dynamic sites, there are few platforms as mature and ubiquitous as WordPress.

I have a love-hate relationship with PHP (and JavaScript for that matter). I hate it in the same way that I hate x86: it’s a platypus that succeeds in spite of its uniqueness not because of it. Consider for example Caddy, our web server. It’s asynchronous like JavaScript, but there is no global interpreter lock or single threaded event loop. It’s featureful, low resource, memory safe, and it can exploit as much parallelism as the hardware and software architecture permit with its excellent goroutines. Garbage collection largely eliminates memory leaks. Go is a really great answer to server space issues without even touching the static, dependency-free, self-contained binaries.

But PHP? Worker processes. Max requests. Extensions. It works but man, it’s not sexy. Greater developers than I have served quite literally billions of users with PHP at the core. PHP is the internet in the powerful sense that x86 is the desktop computer.

I think I struggled because I’m not a web guy, and I use a less common configuration of Caddy and PHP compared to the much more popular Apache. Nobody told me I had to serve files as well as the results of the PHP application. Like in many fields, I found a chasm between expert books and novice tutorials where I didn’t understand the expert resources but the novice examples made assumptions I didn’t. I want Caddy because I love Go, I want a more modernized configuration interface through JSON, and taking a strong stance on enforcing HTTPS matters.

I characterize my final configuration as “simple, if you know what you’re doing.” There are no hacks or clever shortcuts, no fancy customization beyond careful configuration choices. For example, the server is lazy, only running worker processes when needed because this site is idle almost all the time. I would shut
down the database too if I could get away with it because visitors should be preciously rare, but the startup time is quite long. If anyone reads this even once, that’s pretty incredible, ergo I have to do this for myself and the maybe.

Hosting this server myself is one of those things I do because I can, because I want to, because I’m getting older and want to experience the Internet from a new angle.