For me, it's that I'm constantly bitten by nginx vs nginx plus, having to lookup hacks to do the most basic things. There's just a ton of friction to configurating nginx from scratch which, IMO, isn't there with caddy.

Both are great technologies and I use them both. My way of thinking these days is "use Caddy until there is a reason for nginx". When I am developing a web application say I use Caddy in my dev server and use as a proxy for my front end server so you get hot reloading and stuff and the the backend dev server. You need to have three things up but works for me. It's nice to have a single binary!

Yeah. tldr:

- Both Caddy and nginx are really fast.

- Both can handle high traffic loads.

- Caddy and nginx have different failure modes. Nginx will drop requests. Caddy will hang onto them and serve them even if it takes longer.

(Note that "Caddy" is basically equivalent to "Go" -- we use its std lib HTTP implementation. It's really comparing Go and C.)

So I've been slowly moving from nginx to Caddy in new projects (old projects still use nginx).

The reasons for this are:

1. Automatic ACME integration in Caddy compared to the mess of containers something like nginx-proxy-manager is or the unreliability of external solutions like certbot or acme.sh

2. nginx's config. Footguns like if are well known, but even just if you want to deploy a nginx server with virtual hosts, did you know that if there is no Host header nginx serves the site evaluated first in its config file (even if the site has a server_name directive)? This is fine for an enterprise deployment where you probably only have one site behind nginx anyway, but as someone who has their side projects share servers to cut down on costs, it's really undesirable. There is a way around it by setting up a default host to explicitly serve errors, but it's just a chore I don't have on Caddy.

3. I can use Caddy on the CLI for testing also, in a way that's a more advanced replacement for python -m http.server etc. for more advanced use cases, or even just setting up server config rules.

> did you know that if there is no Host header nginx serves the site evaluated first in its config file (even if the site has a server_name directive)?

Before that it goes to the one named "" and if that doesn't exist, the one with default_server.

If traffic with no Host header went to no server by default, people would also call that a footgun...

Setting a server_name is something you need to opt into. So I feel it should be required to match to serve that vhost. If you didn't want it to apply only to the right vhost, don't configure it to require a specific vhost?

Regarding #1, NGINX has created a project to make ACME integration easier. It is quite new, so I doubt it will replace your use of Caddy, but it is worth consideration.

https://github.com/nginx/njs-acme