> 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.
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).
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
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.
I played with Caddy a lot in the v1 days and again recently with v2.1. I ended up not sticking with it since there's things I do with nginx that aren't easy to do with Caddy if you don't have extensive Go knowledge. I am tempted to give it an honest go again, though, and see what I/it can do.
As for Caddy advantages, I think it's really just about having a super easy to manage JSON or Caddyfile. In migrating a few of my nginx configs to Caddyfile, I was able to reduce line counts from dozens to 2-3. That's pretty impressive, tbh.
If you've been using nginx forever and have no issues with it...I don't see any valid reasons to move to Caddy.
The only out-of-box thing I sometimes miss, is "try-files-first" -- but I'll also say it probably is a bit of an anti-pattern (just have static files under another path/sub-domain - etc).
But it is something that nginx does have. That, and maybe some kind of "x-send-file" acelleration/support.
Ed: this is odd, I could've sworn it wasn't that long ago I looked for and even discussed try-files-first for v2 - but apparently it exists?
A production caddy config can be three lines or so.
It's a lot easier for simple things.
Being a single go binary means it "comes with" tls code (for better or worse). Makes it trivial to run a modern proxy on an old distro (say running some old application server that only speaks http, or worse, ancient ssl).
Uprades are quite easy too (drop in a new binary).
It can do many of the things nginx or apache can do, simpler, with less config (less to tune, less to audit).
I used it once for a little proof-of-concept where I needed quick turnaround. It was really easy to configure and had a bunch of features built-in that were convenient and saved a lot of time compared to alternatives.
