Were the Nginx/Apache defaults bad at the time of creation? Has hardware changed? Security? Protocol versions?
Which is to say, in N years, will the Caddy defaults be full of some unfortunate decisions?
Caddy and Traefik have been around for a while now, so curious what has prevented the boring technology from essentially flipping some defaults around.
IMO a big reason is simply because they're written in C, which greatly slows down progress due to having to write a lot more code to do the same thing as higher level languages, and having to take significantly more care about memory safety issues. Caddy and Traefik being written in Go inherently solves both those problems, in addition to being built on top of Go's fantastic http and crypto stdlib packages which does the vast majority of the heavy lifting for implementing a compliant server. The remainder is mostly the config layer and middleware/admin/compatibility pieces (oversimplifying of course) which is where we can spend all our focus, being freed from having to be concerned about protocol level stuff (for the most part).
Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).
A little bit of all the above. I had to spend a lot more time configuring Nginx to use the recommended TLS algorithms. Caddy also supports HTTP/2 and HTTP/3 by default, no config required.
And those good defaults matter. If I pin down a set of TLS protocols today, will those still be good choices a couple of years from now? I don’t know. I’ll bet the then-current version of Caddy will still have good default settings. If HTTP/4 comes along, I suspect Caddy will configure it correctly on my site without me doing anything other than upgrading to a newer version, while other servers will want me to explicitly update their configs to enable it.
The main difference (as someone who is familiar with nginx and caddy, and whose Apache knowledge mostly comes from the era of "webapps are folders in your root with PHP files in them", so not very good) is that Nginx tends to be a very hands-off webserver. It doesn't do anything for you that the config files don't specify it should do. Of the three main ways to serve web content out there (static, CGI-esque aka PHP or a reverse proxy), nginx only really has a near config free experience (as in, your distro probably shipped a default config to make this work with zero effort) for serving static files - you just make a server block, a location block and point the root to the folder you want to serve. Setting up PHP or reverse proxies requires a lot more manual work; if you want X-Forwarded-* headers, you're gonna have to set those up for example.
Similarly, nginx isn't going to be the one picking your SSL config out of the box; it's a bunch of arcane flags and settings (if you're not intimately familiar with SSL anyways) that you look up once how to get the SSLabs A+ score and then you put it in a reusable snippet to not have to think about that stuff ever again for future domains. If you want ACME certificates, you're gonna have to tell it to do that (nginx recently got a module for this I think, which kinda makes it equal in this sense to caddy's automatic LE cert generation) or where to find the certificates.
Caddy automates a lot of this sort of thing; the result is smoother/cleaner config files (it's hard to deny that reverse_proxy is shorter than the several dozens of config lines you'd use for nginx) but you also need to be aware of what Caddy does by default and the assumption that what the Caddy developers think should be the default will also always be what you want, unless you want to poke at manual overrides (in which case it's pretty much nginx again.) It can also do a few common variants on static site hosting, like automatically pulling a git repo, running a page generator on it and serving the resulting folder, which nginx just straight up doesn't do afaik.
In practice, I found Caddy works well on development/toy machines where there's no real expectations for having to think about prod and "not having to spend an hour reconfiguring your setup" when you start a project is beneficial and it's easy to swap things like ports around. Nginx works better on production machines because you basically set it up once and then can safely never have to think about it again, while still allowing you explicitly see why it's (not) doing what you want later down the line.
Traefik I legitimately couldn't see a reason to use however. It's config syntax is atrocious and looking it up online tells me it's mainly popular with non-technical homelab people because it can serve a web UI to manage your reverse proxies in. I guess that's a desirable feature for some?
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.
Which is to say, in N years, will the Caddy defaults be full of some unfortunate decisions?
Caddy and Traefik have been around for a while now, so curious what has prevented the boring technology from essentially flipping some defaults around.