There were a few years where Apache was playing catch-up to nginx, but they were short-lived, and you would be well-served by re-examining it, as I am always reading these threads shaking my head at how much people praise these random tools for doing X or Y or whatever, and Apache just handles it all (including ACME, since 2017), with maybe a few extra lines of configuration, while being so insanely extensible that basic things like how it handles sockets or what protocol it speaks are modules. It just hits a really nice sweet spot between all of these other tools.
I have an old-school sysadmin background, and was responsible for some seriously large Apache installations in the 2000s. I stuck with it during the dark days of the introduction of mpm_worker, and could probably still churn out mod_rewrite rules in my sleep.
Would I use it for a new service today? No.
Not because the configuration itself is complex (as I say, I've been working with it for decades), but because managing the config is complex.
You end up using custom templating systems, testing the new config oob, and then sending signals to the daemon. There's a huge pile of scripting needed to manage all of this in even the most basic way, let alone integrate it with a service mesh or orchestration system.
Even the ASF will push you towards ATS or Dubbo or APISIX rather than old-school Apache Server.
Caddy will get you up and running in seconds, whereas forcing Apache's square peg into the modern environment's round hole is going eat weeks for very little benefit.
I could've written much the same. I used Apache from the late nineties until around 2010, and I can manage it. I just don't want to anymore. It's not worth the pain.
Ok, that's fair: it is always quite disappointing when a project lies about its status (and if I ever get a chance to complain directly about that, I probably will)... but, at least it used to be accurate (and likely was until very recently)? A lot of projects (I see this often with terminal apps) say stuff like "the fastest X", only, when you do a benchmark, they aren't even fast in an absolute sense, much less in a relative sense to other projects (and I believe I remember this being the case for nginx for a while vs. Apache with mpm_event).
I might actually do that; like I said, I mostly just moved on to nginx eventually because it happened to fit how I wanted to configure a server. It was mostly me comparing nginx to caddy.
One thing I did like about Apache back in the day was that it made it really easy to give per served web folder configuration. Nowadays I just toss stuff on a subdomain (cuz there's little reason not to), but if you only have one hostname to put things on (ie. a homelab thatt you can only access by local IP address), that's obviously not an option. .htaccess files were pretty neat for doing that.
Nginx can't really do that as easily, you have to start futzing with different location blocks and it kinda gets messy quickly.
On a not-so-relevant note, I do think Apache has probably the nicest "dirlist" out of all of them. Nginx's is really ugly and Caddy's feels too overdesigned.
You can easily customize Caddy's browse template to your liking. It's just a text file, you can take the default and modify it, or write your own from scratch if you like. See https://caddyserver.com/docs/caddyfile/directives/file_serve... Some users have posted theirs on the forums as well if you need more inspiration.
