The parent comment asked why Caddy is better than Nginx but I'm not sure some of these are applicable.

> Built with Go, so memory safety is essentially solved

Has there been any memory safety issues with Nginx?

> Very pluggable if you need to add additional behaviour

Nginx is easily extendable and has far, far larger plugin ecosystem than Caddy.

> Config API with graceful reloads

So does nginx, with "nginx -s reload"

> Has there been any memory safety issues with Nginx?

Yes, of course. For example, nginx uses openssl, so it was vulnerable to Heartbleed, something Caddy can never be vulnerable to. Part of the point of Caddy is to stop deploying C code to the edge.

> Nginx is easily extendable and has far, far larger plugin ecosystem than Caddy.

Nginx is also 4x older. I'd say for just a few years we're doing pretty good with our very young plugin ecosystem. A lot of this depends on the community. If you want it, make it so!

> So does nginx, with "nginx -s reload"

I think he was referring to a REST/JSON API that isn't unix-specific.

Good point about openssl!

> Nginx is also 4x older.

I know, but the GP claimed Caddy's plugin ecosystem was an advantage over Nginx, which just isn't true.

> I think he was referring to a REST/JSON API that isn't unix-specific.

Got it, thanks. Though I wonder how many people actually need a REST API for config reloads given practically everyone runs servers on Linux.

You'd be surprised how helpful having a REST API for config reloads is when you're serving more than a simple static site.

In addition to OpenSSL's Heartbleed, nginx had its own functionally-identical "Heartbleed" bug in its header parsing. Exact same impact.

(I don't think anyone made a big deal about it at the time; I knew about it because our team at Matasano discovered it independently just an hour or two before someone else filed the bug).

These 2:

- Built-in ACME client, automated certificate management

- Simpler configuration language, the Caddyfile

Are absolutely applicable and reasons that it's better. UX matters.

I'd argue it's much easier to write Go plugins for Caddy than C plugins for nginx, and it's much easier to build. See the plugin docs here: https://caddyserver.com/docs/extending-caddy

On the other hand, it's probably easier to write Lua for nginx?

More people write/know Go than Lua judging from the relative books, posts, job postings, conference sizes, and so on though...

First: Thanks for contributing to Caddy! I have not used it in production, but it has been nice for some small projects where I needed something fast and easy.

But, I do feel like in a discussion where you are making a direct comparison between a project you are a part of and a competing project, it is the fair thing to do to disclose that you are a project member.

I know you're not trying to hide it - I see you making comments elsewhere in here that reference it - but not everyone will necessarily see those, and people would probably like to know if they are reading a comparison written by someone who has a vested interest in the things being compared.