- Built-in ACME client, automated certificate management

- Simpler configuration language, the Caddyfile

- Single static binary, no external dependencies

- Built with Go, so memory safety is essentially solved

- Very pluggable if you need to add additional behaviour (simple Go module plugin system)

- Config API with graceful reloads

- Plenty more, just scroll through the homepage to get an idea: https://caddyserver.com/

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.

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?

https://caddy.community/t/v2-try-file-server-first/6440/3

https://caddyserver.com/docs/caddyfile/directives/try_files#...

Ed2: I guess I was confusing it with x-send-file acelleration - which still appear to be a bit wip? :

https://caddy.community/t/caddy-2-x-sendfile-x-accel-support...

https://caddy.community/t/sendfile-x-accel-redirect-v1s-inte...

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.