Moving to Caddy
As part of my recent host move, I decided it was time to review my web server situation. Specifically, I decided to move on from Apache. It’s served me well over twenty years, and adapted to all of the changes I’ve thrown at it (most notably HTTPS), but my configuration was a tangle of two decade’s of cruft, and since I started other options have emerged that would be more directly applicable to my use case. The switch presented an opportunity to start with a clean slate, so I took it.
My initial plan was to move to nginx, as I’m already very familiar with it, and was confident it would do what I need. However, my friend and colleague Cal suggested I take a look at Caddy, and this turned out to be a very good call.
Caddy is a relatively new kid on the block, and I’d only previously looked at it in its very early days. Coming back to it, it’s now a fully-fledged, production-ready web server, with a few tricks up its sleeve. The most obvious, and most widely applicable, is that it automates the serving of HTTPS, right down to requesting certificates from Let’s Encrypt. Moreover, it touts streamlined configuration that’s so simple you can be up and running in minutes, rather than hours.
This all sounded too good to be true, but I gave it a go and it was 100% on the money. I had a fully working copy of this site, including HTTPS, up in well under 15 minutes (including installing Caddy itself), and by the end of half an hour had sorted out all of the weird redirection and legacy HTTP stuff I wanted to and switch over the DNS. It really is as easy as they claim, at least for the sort of things I want to do.
Of course, nothing is perfect. I suspect there are plenty of edge cases that it can’t handle as well as other options, and for very high volume usage you can find better performing options. Those caveats only apply to a small minority of users, though. If you are within the (very wide) range of what Caddy can do, it’s hard to beat.