Why I Tested 5 Web Servers Before Settling on Caddy

When I first set up a Linux server, I assumed the web server was just a detail. Pick the popular one, follow the tutorial, move on. That assumption cost me weeks of debugging, a certificate that wouldn't renew, and a reverse proxy config that worked until it suddenly didn't. Eventually I tested five different web servers before I found the one that actually fit how I work.

This isn't a benchmark post. It's a practical account of what each server was like to configure and maintain without a sysadmin background — using AI as the primary help source.

Nginx — The Obvious First Choice

Nginx is what every tutorial recommends. It's fast, widely documented, and handles high traffic well. The configuration language is also completely unintuitive until you've read it enough times to internalise the pattern.

The config blocks, the location directives, the difference between root and alias — these are the kind of things where a small mistake causes a silent failure. HTTPS required Certbot and a cron job that I had to set up manually and hope would keep running. The reverse proxy setup for my Node app was about 20 lines of boilerplate I had to find, adapt, and hope I hadn't misunderstood.

It worked. But every time I needed to change something, I was reading the same documentation again.

Apache — Even More Config

Apache is older than Nginx and it shows — not in performance, but in the mental model. The .htaccess file approach means configuration is scattered across directories rather than centralised. That's a feature for shared hosting, not for a server you control entirely. I spent more time understanding the config than making it do what I needed.

When I asked AI to help debug an Apache issue, the answers were longer and more conditional than for any other server. There are too many ways to configure the same thing, which means too many ways to get it subtly wrong.

LiteSpeed — Fast, But Not Free

LiteSpeed is genuinely fast, particularly for PHP workloads. But the full version requires a commercial licence that costs more than my server. The free OpenLiteSpeed version is capable but missing features I needed. The cost-benefit didn't work for where I was at the time.

Varnish — Wrong Tool

I misunderstood what Varnish was. I'd seen it mentioned alongside other web servers and assumed it was one. It's a cache accelerator — it sits in front of a web server and caches responses, it doesn't serve requests itself. Once I understood that, I realised it solved a different problem than the one I had. I was trying to serve applications, not cache a high-traffic static site.

"The most useful thing Varnish taught me was to understand what a tool actually does before spending a week trying to make it do something else."

H2O — Almost

H2O is modern, genuinely fast, and HTTP/2 native by design. I wanted it to work. The problem was the community — small enough that documentation gaps were common, and small enough that AI had limited training data for edge cases. When something broke, the path to a fix was long. That's a real cost when you're debugging at midnight after a full day on site.

Caddy — Why It Won

Caddy does two things differently from every other web server I tested:

The automatic HTTPS alone is worth it. On Nginx, certificate renewal is a cron job that silently fails if something changes. On Caddy, it's not a thing you think about. Caddy handles it, renews it, and I've never had a certificate issue since switching.

The Caddyfile is also just readable. I can look at a config I wrote six months ago and understand what it does without reverse-engineering the logic. For a solo builder who touches a lot of different parts of the stack, that legibility compounds over time.

All FixFlex projects — Sentinel, 24ad.info, FixFlex itself — run behind Caddy. It's been the one infrastructure choice I haven't second-guessed.