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.
> 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.
(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).
- Built-in ACME client, automated certificate management
- Simpler configuration language, the Caddyfile
Are absolutely applicable and reasons that it's better. UX matters.
> 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"