Is that factual, or also something you feel like?

To us simple folks, you know, it looks as if Caddy has a number of use cases where it's a much neater fit than nginx. We like the extreme simplicity and the transparency of it all. Some of us also like the Go it's written in. What with the magic Go modularity, you can actually embed this server in your web-app. Or is it the other way round? Comes in handy, at any rate.

It's the other way round.

You can embed your app in the server if you want to get its features for free, though given it uses net/http and most of the features are exposed there you should probably just use that directly instead if you are doing anything significant.

Caddy isn't the universal solution, but it sounds like you're rationalizing using the more complex tool because you know it and have been using it rather than because it's necessarily superior.

Every single thing I've done, could be implemented in an opinionated away by the web server. I'd love to just say "php" and have it do the right thing.

In fact, I'd go as far as to say, it would be amazing if I could just say "proxy ____ drupal" instead of php, and it'll add the drupal rules as well.

I can set up both nginx and apache (and get paid for it), I've automated LE for new sites via ansible, etc. Nowadays if I can do with caddy, I just use that and proceed to the next task. Also remember that easy (and short) configuration means easier maintenance.

Devs also love it, they can develop locally using advanced functionality (e.g proxying an API that doesn't provide CORS).

Go is ona average 3x slower than C according to bechmarks, and it's hard to get rid of this issue because of how the language is architected. I just don't see Caddy as a possible long term replacement for nginx.