7 ms·

Caddy – a modern web server (vs. Nginx)

62 points by n1try 10y ago

popey456963 10y ago
Some of your links to https://caddyserver.com/ https://caddyserver.com/ are relative and not absolute, leading me to https://ferdinand-muetsch.de/caddyserver.com https://ferdinand-muetsch.de/caddyserver.com - Something you should consider fixing. All in all however, I like the look of Caddy. The best bit I feel has been left out though: "That is why, effective this release, Caddy will automatically serve all live sites over HTTPS without user intervention." Which I think is just brilliant.
- n1try 10y ago
  Thanks for that hint, I fixed the link! I think I mentioned that HTTPS is on by default, didn't I? But anyway, yes it's very useful and a good practice.
notheguyouthink 10y ago
> You don’t need to run any script. You don’t even need to create a Let’s Encrypt account or install the certbot. How is this done? Ie, to not need any account and still get new/valid certs. And, on that note, what is the difference between having an account and not? Eg, how might using no accounts harm a production environment? Just trying to wrap my head around that. Really cool UX for side stuff! edit: Ah, looks like there is an account involved - it creates one, possibly using your email address. This makes more sense now.
- n1try 10y ago
  Yes, right. Maybe I should've mentioned that. But I didn't want to talk to much about the certs.
richardwhiuk 10y ago
The graph is marked as 'Apache2 vs. nginx memory usage ' but that's not what it shows at all - it's 'Requests per second on Apachev2 vs nginx' - did you mean to show https://objects-us-west-1.dream.io/kbimages/images/Webserver_memory_graph.jpg https://objects-us-west-1.dream.io/kbimages/images/Webserver... instead?
- n1try 10y ago
  Yes, right, that was a mistake. Thank you very much!
- richardwhiuk 10y ago
  Also, this article is really odd. It starts with a performance based analysis comparison of a bunch of web servers, and then decides to add a third completely unknown option, and then decides it's better, based on it's configuration being 'better' (in a way that's not shown), despite it's performance being ~ 1/3 of the competitor....
  - n1try 10y ago
    My goal was to point some attention to Caddy as well as to outline why I switched from nginx (as well as the tradeoff between simplicity and performance). Maybe you're right and mentioning Apache and IIS was confusing.
    - mtdewcmu 10y ago
      It wasn't that confusing, but I guess it's not clear what the takeaway should be from the article. Since you started off by talking about apache's memory usage, it would have made sense to include a graph showing Caddy's memory usage vs apache. Since neither apache nor Caddy can touch nginx in terms of performance, the tradeoff between nginx and Caddy is clear: speed vs ease of setup. It's not clear where Caddy falls relative to apache. You sort of explained why you didn't do this stuff (apache still doesn't support http2), but perhaps you could rewrite the conclusion and maybe make some guesses as to how apache and Caddy will compare, once apache gets http2? And try to answer the question -- "should I use Caddy now or wait for apache to support http2?"
      - richardwhiuk 10y ago
        It's not clear that Caddy wins on speed of setup though over nginx though. More that the author wanted something...different.
notacoward 10y ago
> every middleware you want to use needs to be included into the binary and if it’s not, you need to re-compile the program Having to recompile to add functionality that alternatives provide as dynamically loaded plugins is insane. This is 2017. Linux has had loadable kernel modules since 1995, and I worked on them for other versions of UNIX as far back as 1991. I understand that it's hard for a Go program to support plugins written in other languages using a more conventional runtime. No problem there. However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime. I really want to like Go, but as long as the Go community clings to long-discredited ideas regarding things like packaging and distribution and symbol versioning I just don't feel like I can depend on it to build infrastructure that will remain robust over time.
- notheguyouthink 10y ago
  > I really want to like Go, but as long as the Go community clings to long-discredited ideas regarding I'm confused, aren't Go plugins exactly the feature you want? And on that note, it was just introduced as of 1.8, wasn't it? Seems a bit harsh to criticize a project for not using (during it's development time) unfinished and not production ready features.
  - notacoward 10y ago
    See my response to mholt in this thread. I wasn't criticizing Caddy so much as Go itself. Go has been around for about seven years now. While it's nice that such an obvious and serious shortcoming has been addressed recently, it has still taken way too long IMO. Plus, we're still stuck with "vendoring" and other community-embraced practices that are bad for long-term maintainability. People have been led in a bad direction, and I'm not about to let the leaders off the hook for that.
- n1try 10y ago
  Yes, I agree with you that this is not very helpful, especially for larger production environments. I don't know if they might refactor the middleware system to a more dynamic way some time.
tannhaeuser 10y ago
I like caddy, but the dreamhost benchmark re apache vs nginx isn't really telling, as it doesn't mention fundamental apache config properties. I'm assuming they were benchmarking an unoptimized MPM/prefork setup, but you can use event-based request processing (and other process models) with apache as well. There's nothing magical with nginx. I'd also like to see a benchmark vs. H2O which seems to have the most advanced HTTP/2 support right now (its running the nghttp2 web site for some time now).
- bwblabs 10y ago
  Any experiences with running h2o on production sites? The documentation is a bit lacking sometimes, luckily the code is well written.
  - n1try 10y ago
    I'd be interested in such experiences, too. H2O look promising at first sight.
  - tannhaeuser 10y ago
    No experience with h2o yet. I'm not keen on having to pickup Ruby which would be just one more thing to take care of for me.
    - bwblabs 10y ago
      The code is mainly written in C (https://github.com/h2o/h2o https://github.com/h2o/h2o) with some Perl testing. The Mruby for small (header/push) logic isn't that bad, and not bad in terms of performance either (https://h2o.examp1e.net/configure/mruby.html https://h2o.examp1e.net/configure/mruby.html), although I'm also not a Ruby fan.
kmeade 10y ago
Shortcomings of the article aside, I'd like to say that I use Caddy for a set of small websites and I couldn't really be happier with it. I'm a longtime Windows developer who doesn't have much patience with nerdy complexities. I started in 1996 with a buggy, gawd-awful Netscape webserver, moved to the late-lamented O'Reilly WebSite (even had a T-Shirt) and reluctantly settled on MS IIS, with occasional Apache encounters. Caddy has been an absolute breath of fresh air. I currently run 4 sites from a system at my home, using Namecheap dynamic DNS. Caddy serves the basic web pages and static content and also reverse proxies to an internal Python server for dynamic content. Sounds a little complicated, but believe me, configuration is dead-simple thanks to Caddy. Plus I get full HTTPS from Let's Encrypt for the cost of supplying my email address and agreeing to a EULA - no configuration needed at all. I've never used a webserver that was easier to configure or had such low resource requirements.
- VT_Drew 10y ago
  >I'm a longtime Windows developer who doesn't have much patience with nerdy complexities. That is funny because I have setup Apache, Nginx, and IIS web servers before and by far the one I found to have the most nerdy complexities is IIS.
  - tracker1 10y ago
    I think it's often easier because most of the nerdy complexities are via a GUI... though the web.config offers a lot more in more recent versions. And adding in Application Request Routing (reverse-proxy) and the like can get complicated quickly, it's not nearly as bad as either nginx or apache tend to be. I do like what nginx can do combined with lua though, it's pretty damned cool. All in all, I do like Caddy's defaults and out of the box for newer tech. I haven't really tried it much, mostly out of complacency with nginx/iis in Linux/windows. And I will definitely never run Apache on a new box again.
    - kmeade 10y ago
      I agree with both posts above me. While I normally prefer a GUI configuration facility, I wouldn't make the argument that IIS is particularly simpler than Apache. Getting back to Caddy, configuration is so simple, a GUI would be overkill. Here's an (entire) example of how to configure a reverse proxy in Caddy... proxy / 127.0.0.1:8080 { except /favicon.ico /robots.txt /assets /plainpages /staticstuff /test1 proxy_header X-Forwarded-Proto {scheme} } The "except" line is a list of files and directories that are statically served by Caddy. All other content comes from a local server on port 8080. The "proxy_header" line lets the 2nd server know when contents are being sent as secured (HTTPS) Isn't that nice? I think so.
spilk 10y ago
Does Caddy support client certificates?
- mholt 10y ago
  Yes. https://caddyserver.com/docs/tls https://caddyserver.com/docs/tls
  - spilk 10y ago
    Is the certificate or its parameters (subject/issuer/alt names/etc) available to set downstream headers (for proxy/fastcgi)? I'm sure I'm missing it, but can't see anything like that in the docs. Or is this something that is more suitable for a plugin?
    - mholt 10y ago
      I'm not sure I understand the question. You want a TLS certificate to set HTTP headers?
      - spilk 10y ago
        Yes - X.509 client certificates are the authentication mechanism (TLS mutual authentication). How this generally works with other HTTP servers (i.e. nginx) is the proxy validates that the client's certificate are issued by a given authority and valid/not revoked, then injects headers with the certificate subject or other certificate fields (commonly a UPN in the subject alternative name) to tell the proxied application the identity of the user. nginx's TLS implementation populates variables with the various client certificate variables for use elsewhere (the $ssl_client* variables here: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables http://nginx.org/en/docs/http/ngx_http_ssl_module.html#varia... ) In other cases, the entire client certificate is injected into a header (in PEM format) for the downstream application to process as it pleases. This is a common use case in US Government since everyone carries X.509 certificates around their neck (ID badge is also a PIV smartcard). US Government usually implements this with F5 BIG-IP appliances but I usually use nginx.
VT_Drew 10y ago
>The configuration is not that intuitive and you really need to get into the syntax and concepts to get an understanding of knobs to turn in order to achieve a certain goal. Personally I found Nginx configuration much simpler than Apache. I think Nginx is pretty intuitive, it certainly is much supplier than IIS, which is a nightmare.
joshstrange 10y ago
I like caddy and I use in inside of docker for my private home/cloud setup but lately I've been rethinking even that. I agree it's almost magical in how easy it is to setup (especially with HTTPS) but I use nginx for serious projects and a large part of me says it's better to use the same thing everywhere to keep me up to date and aware of potential issues or features and not mix the two.
dsl 10y ago
This looks awesome. I'd switch away in a heartbeat if the Let's Encrypt integration could handle multi-server deployments.
mwpmaybe 10y ago
I've been experimenting with Caddy over the past few days and it's great, if somewhat immature and quirky. The plugin ecosystem is rich but in dire need of some oversight and QC. What I like most about Caddy is its very sane behavior out of the box: it just does the right thing in most cases, and requires much less configuration than NGINX, Apache, HAProxy, etc. (It also has fewer features, so there's a trade-off.) I posted a gist[0] with my Caddy+Varnish+PHP-FPM configuration and a README explaining the hows and whys. I'm moving a bunch of WordPress sites from Apache/mod_php to this configuration (each site's PHP-FPM instance is Dockerized, but that's out of the scope of the gist). Hopefully someone finds it helpful! 0. https://gist.github.com/mwpastore/f42f6f1309a7b067519f4c08e18b0b6a https://gist.github.com/mwpastore/f42f6f1309a7b067519f4c08e1...

62 points by n1try 10y ago

Some of your links to https://caddyserver.com/ https://caddyserver.com/ are relative and not absolute, leading me to https://ferdinand-muetsch.de/caddyserver.com https://ferdinand-muetsch.de/caddyserver.com - Something you should consider fixing. All in all however, I like the look of Caddy. The best bit I feel has been left out though: "That is why, effective this release, Caddy will automatically serve all live sites over HTTPS without user intervention." Which I think is just brilliant.

n1try 10y ago
Thanks for that hint, I fixed the link! I think I mentioned that HTTPS is on by default, didn't I? But anyway, yes it's very useful and a good practice.

notheguyouthink 10y ago

> You don’t need to run any script. You don’t even need to create a Let’s Encrypt account or install the certbot. How is this done? Ie, to not need any account and still get new/valid certs. And, on that note, what is the difference between having an account and not? Eg, how might using no accounts harm a production environment? Just trying to wrap my head around that. Really cool UX for side stuff! edit: Ah, looks like there is an account involved - it creates one, possibly using your email address. This makes more sense now.

n1try 10y ago
Yes, right. Maybe I should've mentioned that. But I didn't want to talk to much about the certs.

richardwhiuk 10y ago

The graph is marked as 'Apache2 vs. nginx memory usage ' but that's not what it shows at all - it's 'Requests per second on Apachev2 vs nginx' - did you mean to show https://objects-us-west-1.dream.io/kbimages/images/Webserver_memory_graph.jpg https://objects-us-west-1.dream.io/kbimages/images/Webserver... instead?

n1try 10y ago
Yes, right, that was a mistake. Thank you very much!
richardwhiuk 10y ago
Also, this article is really odd. It starts with a performance based analysis comparison of a bunch of web servers, and then decides to add a third completely unknown option, and then decides it's better, based on it's configuration being 'better' (in a way that's not shown), despite it's performance being ~ 1/3 of the competitor....
- n1try 10y ago
  My goal was to point some attention to Caddy as well as to outline why I switched from nginx (as well as the tradeoff between simplicity and performance). Maybe you're right and mentioning Apache and IIS was confusing.
  - mtdewcmu 10y ago
    It wasn't that confusing, but I guess it's not clear what the takeaway should be from the article. Since you started off by talking about apache's memory usage, it would have made sense to include a graph showing Caddy's memory usage vs apache. Since neither apache nor Caddy can touch nginx in terms of performance, the tradeoff between nginx and Caddy is clear: speed vs ease of setup. It's not clear where Caddy falls relative to apache. You sort of explained why you didn't do this stuff (apache still doesn't support http2), but perhaps you could rewrite the conclusion and maybe make some guesses as to how apache and Caddy will compare, once apache gets http2? And try to answer the question -- "should I use Caddy now or wait for apache to support http2?"
    - richardwhiuk 10y ago
      It's not clear that Caddy wins on speed of setup though over nginx though. More that the author wanted something...different.

notacoward 10y ago

> every middleware you want to use needs to be included into the binary and if it’s not, you need to re-compile the program Having to recompile to add functionality that alternatives provide as dynamically loaded plugins is insane. This is 2017. Linux has had loadable kernel modules since 1995, and I worked on them for other versions of UNIX as far back as 1991. I understand that it's hard for a Go program to support plugins written in other languages using a more conventional runtime. No problem there. However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime. I really want to like Go, but as long as the Go community clings to long-discredited ideas regarding things like packaging and distribution and symbol versioning I just don't feel like I can depend on it to build infrastructure that will remain robust over time.

notheguyouthink 10y ago
> I really want to like Go, but as long as the Go community clings to long-discredited ideas regarding I'm confused, aren't Go plugins exactly the feature you want? And on that note, it was just introduced as of 1.8, wasn't it? Seems a bit harsh to criticize a project for not using (during it's development time) unfinished and not production ready features.
- notacoward 10y ago
  See my response to mholt in this thread. I wasn't criticizing Caddy so much as Go itself. Go has been around for about seven years now. While it's nice that such an obvious and serious shortcoming has been addressed recently, it has still taken way too long IMO. Plus, we're still stuck with "vendoring" and other community-embraced practices that are bad for long-term maintainability. People have been led in a bad direction, and I'm not about to let the leaders off the hook for that.
n1try 10y ago
Yes, I agree with you that this is not very helpful, especially for larger production environments. I don't know if they might refactor the middleware system to a more dynamic way some time.

tannhaeuser 10y ago

I like caddy, but the dreamhost benchmark re apache vs nginx isn't really telling, as it doesn't mention fundamental apache config properties. I'm assuming they were benchmarking an unoptimized MPM/prefork setup, but you can use event-based request processing (and other process models) with apache as well. There's nothing magical with nginx. I'd also like to see a benchmark vs. H2O which seems to have the most advanced HTTP/2 support right now (its running the nghttp2 web site for some time now).

bwblabs 10y ago
Any experiences with running h2o on production sites? The documentation is a bit lacking sometimes, luckily the code is well written.
- n1try 10y ago
  I'd be interested in such experiences, too. H2O look promising at first sight.
- tannhaeuser 10y ago
  No experience with h2o yet. I'm not keen on having to pickup Ruby which would be just one more thing to take care of for me.
  - bwblabs 10y ago
    The code is mainly written in C (https://github.com/h2o/h2o https://github.com/h2o/h2o) with some Perl testing. The Mruby for small (header/push) logic isn't that bad, and not bad in terms of performance either (https://h2o.examp1e.net/configure/mruby.html https://h2o.examp1e.net/configure/mruby.html), although I'm also not a Ruby fan.

kmeade 10y ago

Shortcomings of the article aside, I'd like to say that I use Caddy for a set of small websites and I couldn't really be happier with it. I'm a longtime Windows developer who doesn't have much patience with nerdy complexities. I started in 1996 with a buggy, gawd-awful Netscape webserver, moved to the late-lamented O'Reilly WebSite (even had a T-Shirt) and reluctantly settled on MS IIS, with occasional Apache encounters. Caddy has been an absolute breath of fresh air. I currently run 4 sites from a system at my home, using Namecheap dynamic DNS. Caddy serves the basic web pages and static content and also reverse proxies to an internal Python server for dynamic content. Sounds a little complicated, but believe me, configuration is dead-simple thanks to Caddy. Plus I get full HTTPS from Let's Encrypt for the cost of supplying my email address and agreeing to a EULA - no configuration needed at all. I've never used a webserver that was easier to configure or had such low resource requirements.

VT_Drew 10y ago
>I'm a longtime Windows developer who doesn't have much patience with nerdy complexities. That is funny because I have setup Apache, Nginx, and IIS web servers before and by far the one I found to have the most nerdy complexities is IIS.
- tracker1 10y ago
  I think it's often easier because most of the nerdy complexities are via a GUI... though the web.config offers a lot more in more recent versions. And adding in Application Request Routing (reverse-proxy) and the like can get complicated quickly, it's not nearly as bad as either nginx or apache tend to be. I do like what nginx can do combined with lua though, it's pretty damned cool. All in all, I do like Caddy's defaults and out of the box for newer tech. I haven't really tried it much, mostly out of complacency with nginx/iis in Linux/windows. And I will definitely never run Apache on a new box again.
  - kmeade 10y ago
    I agree with both posts above me. While I normally prefer a GUI configuration facility, I wouldn't make the argument that IIS is particularly simpler than Apache. Getting back to Caddy, configuration is so simple, a GUI would be overkill. Here's an (entire) example of how to configure a reverse proxy in Caddy... proxy / 127.0.0.1:8080 { except /favicon.ico /robots.txt /assets /plainpages /staticstuff /test1 proxy_header X-Forwarded-Proto {scheme} } The "except" line is a list of files and directories that are statically served by Caddy. All other content comes from a local server on port 8080. The "proxy_header" line lets the 2nd server know when contents are being sent as secured (HTTPS) Isn't that nice? I think so.

spilk 10y ago

Does Caddy support client certificates?

mholt 10y ago
Yes. https://caddyserver.com/docs/tls https://caddyserver.com/docs/tls
- spilk 10y ago
  Is the certificate or its parameters (subject/issuer/alt names/etc) available to set downstream headers (for proxy/fastcgi)? I'm sure I'm missing it, but can't see anything like that in the docs. Or is this something that is more suitable for a plugin?
  - mholt 10y ago
    I'm not sure I understand the question. You want a TLS certificate to set HTTP headers?
    - spilk 10y ago
      Yes - X.509 client certificates are the authentication mechanism (TLS mutual authentication). How this generally works with other HTTP servers (i.e. nginx) is the proxy validates that the client's certificate are issued by a given authority and valid/not revoked, then injects headers with the certificate subject or other certificate fields (commonly a UPN in the subject alternative name) to tell the proxied application the identity of the user. nginx's TLS implementation populates variables with the various client certificate variables for use elsewhere (the $ssl_client* variables here: http://nginx.org/en/docs/http/ngx_http_ssl_module.html#variables http://nginx.org/en/docs/http/ngx_http_ssl_module.html#varia... ) In other cases, the entire client certificate is injected into a header (in PEM format) for the downstream application to process as it pleases. This is a common use case in US Government since everyone carries X.509 certificates around their neck (ID badge is also a PIV smartcard). US Government usually implements this with F5 BIG-IP appliances but I usually use nginx.

VT_Drew 10y ago

>The configuration is not that intuitive and you really need to get into the syntax and concepts to get an understanding of knobs to turn in order to achieve a certain goal. Personally I found Nginx configuration much simpler than Apache. I think Nginx is pretty intuitive, it certainly is much supplier than IIS, which is a nightmare.

joshstrange 10y ago

I like caddy and I use in inside of docker for my private home/cloud setup but lately I've been rethinking even that. I agree it's almost magical in how easy it is to setup (especially with HTTPS) but I use nginx for serious projects and a large part of me says it's better to use the same thing everywhere to keep me up to date and aware of potential issues or features and not mix the two.

dsl 10y ago

This looks awesome. I'd switch away in a heartbeat if the Let's Encrypt integration could handle multi-server deployments.

mwpmaybe 10y ago

I've been experimenting with Caddy over the past few days and it's great, if somewhat immature and quirky. The plugin ecosystem is rich but in dire need of some oversight and QC. What I like most about Caddy is its very sane behavior out of the box: it just does the right thing in most cases, and requires much less configuration than NGINX, Apache, HAProxy, etc. (It also has fewer features, so there's a trade-off.) I posted a gist[0] with my Caddy+Varnish+PHP-FPM configuration and a README explaining the hows and whys. I'm moving a bunch of WordPress sites from Apache/mod_php to this configuration (each site's PHP-FPM instance is Dockerized, but that's out of the scope of the gist). Hopefully someone finds it helpful! 0. https://gist.github.com/mwpastore/f42f6f1309a7b067519f4c08e18b0b6a https://gist.github.com/mwpastore/f42f6f1309a7b067519f4c08e1...