5 ms·

These days I'd rather develop on Caddy than Nginx.

dvhh 3y ago
Really depends on your preferred programing language I guess. And the kind of feature you would like to implement.
francislavoie 3y ago
For ref: https://caddyserver.com/docs/extending-caddy https://caddyserver.com/docs/extending-caddy Disclaimer: I help maintain Caddy
dspillett 3y ago
Have there been any good in-depth comparisons of the two recently (from an admin/user PoV, out-of-the-box featureset & performance for common tasks). I've not seen anything recent that isn't entirely superficial (little more than “I prefer the config format”, which while valid isn't exactly in-depth or in-bredth).
- otbutz 3y ago
  https://news.ycombinator.com/item?id=32865497 https://news.ycombinator.com/item?id=32865497
  - mholt 3y ago
    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.)
- DistractionRect 3y ago
  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.
- nhatcher 3y ago
  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, I use Caddy in my dev server 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!
- Macha 3y ago
  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.
  - morelisp 3y ago
    > 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...
    - Macha 3y ago
      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?
  - dekobon 3y ago
    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 https://github.com/nginx/njs-acme
numlock86 3y ago
Caddy is cool if you want sane defaults and not bother with anything for simple hosting. As soon as you get any drop of "not the default" poured into the mix the configuration becomes quite tedious really fast. I recommend Caddy to people getting into web stuff or that need something simple even if it's a production environment at this point. But anything "tuned" ends up with Nginx.
- mholt 3y ago
  We have a lot of larger use cases including enterprise that manage their advanced configurations quite easily. but if you have specific suggestions I'd be happy to consider them.
mholt 3y ago
This is exactly why I made Caddy. :) Glad to hear you also prefer it!
chasd00 3y ago
> These days I'd rather develop on Caddy than Nginx. do you mean develop on Caddy itself or use Caddy as a webserver for a website you're developing?
- commandersaki 3y ago
  I meant developing on Caddy itself. Since it is in Go, it would be remarkably easier than smashing out (async) C. Caddy also has a plugin/module architecture as well.
nicbou 3y ago
I have not tried Caddy much, but Nginx and its numerous footguns are getting a little old. Nowadays I just copy and paste from my own projects. Otherwise I always have to figure which defaults are unreasonable and will bite me when I least expect it. I got Caddy to run on my vacuum cleaner in a few minutes with no prior experience. I think that's pretty cool.
monlockandkey 3y ago
Would love a rust version of caddy. Performance of Cady vs nginx is not as high. But overall an amazing project
- stephane-klein 3y ago
  https://github.com/sozu-proxy/sozu https://github.com/sozu-proxy/sozu
okasaki 3y ago
I got caught in the hype and switched to caddy. After a year I'm now back with nginx and happier than ever. I understand that one can probably methodologically master caddy, but from the perspective of someone who has been running web servers for decades and just needs to get things done, my god, caddy has the worst documentation of any product I've ever seen, and the most confusing configuration I can possibly imagine. Confusion over v1/v2/json/yaml formats, documentation showing tiny snippets without telling how where they fit, etc. Not even ChatGPT4 can write caddy configuration. For a long time I thought that my caddy config was blocking all IPs except the ones I listed. Turns out that no. The shit I wrote did nothing. TLDR: Don't fall for the hype. Nginx is excellent.
- francislavoie 3y ago
  I greatly disagree regarding our docs. Typically the problem is you haven't read https://caddyserver.com/docs/caddyfile/concepts https://caddyserver.com/docs/caddyfile/concepts first which is required to understand where things go. If you're confused, you should ask us for help. Don't just let frustrations simmer. Ask a question on our forums https://caddy.community https://caddy.community.
excitom 3y ago
Irrelevant to this post.

dvhh 3y ago

Really depends on your preferred programing language I guess. And the kind of feature you would like to implement.

For ref: https://caddyserver.com/docs/extending-caddy https://caddyserver.com/docs/extending-caddy Disclaimer: I help maintain Caddy

dspillett 3y ago

Have there been any good in-depth comparisons of the two recently (from an admin/user PoV, out-of-the-box featureset & performance for common tasks). I've not seen anything recent that isn't entirely superficial (little more than “I prefer the config format”, which while valid isn't exactly in-depth or in-bredth).

otbutz 3y ago
https://news.ycombinator.com/item?id=32865497 https://news.ycombinator.com/item?id=32865497
- mholt 3y ago
  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.)
DistractionRect 3y ago
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.
nhatcher 3y ago
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, I use Caddy in my dev server 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!
Macha 3y ago
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.
- morelisp 3y ago
  > 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...
  - Macha 3y ago
    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?
- dekobon 3y ago
  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 https://github.com/nginx/njs-acme

numlock86 3y ago

Caddy is cool if you want sane defaults and not bother with anything for simple hosting. As soon as you get any drop of "not the default" poured into the mix the configuration becomes quite tedious really fast. I recommend Caddy to people getting into web stuff or that need something simple even if it's a production environment at this point. But anything "tuned" ends up with Nginx.

mholt 3y ago
We have a lot of larger use cases including enterprise that manage their advanced configurations quite easily. but if you have specific suggestions I'd be happy to consider them.

mholt 3y ago

This is exactly why I made Caddy. :) Glad to hear you also prefer it!

chasd00 3y ago

> These days I'd rather develop on Caddy than Nginx. do you mean develop on Caddy itself or use Caddy as a webserver for a website you're developing?

commandersaki 3y ago
I meant developing on Caddy itself. Since it is in Go, it would be remarkably easier than smashing out (async) C. Caddy also has a plugin/module architecture as well.

nicbou 3y ago

I have not tried Caddy much, but Nginx and its numerous footguns are getting a little old. Nowadays I just copy and paste from my own projects. Otherwise I always have to figure which defaults are unreasonable and will bite me when I least expect it. I got Caddy to run on my vacuum cleaner in a few minutes with no prior experience. I think that's pretty cool.

monlockandkey 3y ago

Would love a rust version of caddy. Performance of Cady vs nginx is not as high. But overall an amazing project

stephane-klein 3y ago
https://github.com/sozu-proxy/sozu https://github.com/sozu-proxy/sozu

okasaki 3y ago

I got caught in the hype and switched to caddy. After a year I'm now back with nginx and happier than ever. I understand that one can probably methodologically master caddy, but from the perspective of someone who has been running web servers for decades and just needs to get things done, my god, caddy has the worst documentation of any product I've ever seen, and the most confusing configuration I can possibly imagine. Confusion over v1/v2/json/yaml formats, documentation showing tiny snippets without telling how where they fit, etc. Not even ChatGPT4 can write caddy configuration. For a long time I thought that my caddy config was blocking all IPs except the ones I listed. Turns out that no. The shit I wrote did nothing. TLDR: Don't fall for the hype. Nginx is excellent.

francislavoie 3y ago
I greatly disagree regarding our docs. Typically the problem is you haven't read https://caddyserver.com/docs/caddyfile/concepts https://caddyserver.com/docs/caddyfile/concepts first which is required to understand where things go. If you're confused, you should ask us for help. Don't just let frustrations simmer. Ask a question on our forums https://caddy.community https://caddy.community.

excitom 3y ago

Irrelevant to this post.