Next Steps for the Caddy Project Maintainership

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?

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.

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).

That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.

But it’s not only the config that makes Caddy nice. I think that’s a good example of the kind of care and consideration that goes into Caddy’s development, though.

Still, only you and one other person with a similar grudge have ever complained about it (we've never had any github issues opened about it in years, neither on our forums) and nobody who cares has attempted to solve it with code changes.

1. This may have been a misread on my part, on second read, gp's comment says nothing about mandatory payment. The reason I'm wary of mandatory payments is that you'd have to quantify who deserves what, and expend more time on the administration - likey setting up a foundation or company, or which not every F/OSS project needs. Again, I'm speaking generally - a Caddy Foundation, or Caddy Inc. may be appropriate. "Open source project" is a very broad term, ranging in size from leftpad to the Linux kernel, and the needs will be different for each.