7 ms·

It’s nice to see the responsibility spread across more people, open source projects live and die by their maintainers. As a note, Caddy is one of those tools w

It’s nice to see the responsibility spread across more people, open source projects live and die by their maintainers. As a note, Caddy is one of those tools which hits the 80-90% of functionality with 50% of the complexity. For both my homelab and hobby projects it just works. Its configuration is sane and well documented. I highly recommend giving it a try.

tln 1y ago
For me it's been 95% and 5%. Caddy is great!
queenkjuul 1y ago
Caddy rules, i can't imagine using anything else for the kind of projects I'm usually involved with.
kstrauser 1y ago
For those on the fence, imagine Nginx, but with all the defaults set to what you’d have them on in the first place. Here’s a complete configuration file for a Wordpress site with a LetsEncrypt TLS cert, static files, and PHP executed via FastCGI: example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } That’s it. That’s the whole thing. All the other settings are adjustable, but have the default values you’d configure yourself if you wanted to dig in and tweak it. I appreciate Caddy immensely. It doesn’t do anything Nginx can’t do, as far as I know, but it’s a whole lot more ergonomic while doing it.
- 3eb7988a1663 1y ago
  Were the Nginx/Apache defaults bad at the time of creation? Has hardware changed? Security? Protocol versions? Which is to say, in N years, will the Caddy defaults be full of some unfortunate decisions? Caddy and Traefik have been around for a while now, so curious what has prevented the boring technology from essentially flipping some defaults around.
  - francislavoie 1y ago
    IMO a big reason is simply because they're written in C, which greatly slows down progress due to having to write a lot more code to do the same thing as higher level languages, and having to take significantly more care about memory safety issues. Caddy and Traefik being written in Go inherently solves both those problems, in addition to being built on top of Go's fantastic http and crypto stdlib packages which does the vast majority of the heavy lifting for implementing a compliant server. The remainder is mostly the config layer and middleware/admin/compatibility pieces (oversimplifying of course) which is where we can spend all our focus, being freed from having to be concerned about protocol level stuff (for the most part). Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).
  - kstrauser 1y ago
    A little bit of all the above. I had to spend a lot more time configuring Nginx to use the recommended TLS algorithms. Caddy also supports HTTP/2 and HTTP/3 by default, no config required. And those good defaults matter. If I pin down a set of TLS protocols today, will those still be good choices a couple of years from now? I don’t know. I’ll bet the then-current version of Caddy will still have good default settings. If HTTP/4 comes along, I suspect Caddy will configure it correctly on my site without me doing anything other than upgrading to a newer version, while other servers will want me to explicitly update their configs to enable it.
  - noirscape 1y ago
    The main difference (as someone who is familiar with nginx and caddy, and whose Apache knowledge mostly comes from the era of "webapps are folders in your root with PHP files in them", so not very good) is that Nginx tends to be a very hands-off webserver. It doesn't do anything for you that the config files don't specify it should do. Of the three main ways to serve web content out there (static, CGI-esque aka PHP or a reverse proxy), nginx only really has a near config free experience (as in, your distro probably shipped a default config to make this work with zero effort) for serving static files - you just make a server block, a location block and point the root to the folder you want to serve. Setting up PHP or reverse proxies requires a lot more manual work; if you want X-Forwarded-* headers, you're gonna have to set those up for example. Similarly, nginx isn't going to be the one picking your SSL config out of the box; it's a bunch of arcane flags and settings (if you're not intimately familiar with SSL anyways) that you look up once how to get the SSLabs A+ score and then you put it in a reusable snippet to not have to think about that stuff ever again for future domains. If you want ACME certificates, you're gonna have to tell it to do that (nginx recently got a module for this I think, which kinda makes it equal in this sense to caddy's automatic LE cert generation) or where to find the certificates. Caddy automates a lot of this sort of thing; the result is smoother/cleaner config files (it's hard to deny that reverse_proxy is shorter than the several dozens of config lines you'd use for nginx) but you also need to be aware of what Caddy does by default and the assumption that what the Caddy developers think should be the default will also always be what you want, unless you want to poke at manual overrides (in which case it's pretty much nginx again.) It can also do a few common variants on static site hosting, like automatically pulling a git repo, running a page generator on it and serving the resulting folder, which nginx just straight up doesn't do afaik. In practice, I found Caddy works well on development/toy machines where there's no real expectations for having to think about prod and "not having to spend an hour reconfiguring your setup" when you start a project is beneficial and it's easy to swap things like ports around. Nginx works better on production machines because you basically set it up once and then can safely never have to think about it again, while still allowing you explicitly see why it's (not) doing what you want later down the line. Traefik I legitimately couldn't see a reason to use however. It's config syntax is atrocious and looking it up online tells me it's mainly popular with non-technical homelab people because it can serve a web UI to manage your reverse proxies in. I guess that's a desirable feature for some?
- idoubtit 1y ago
  I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box: server { server_name example.com; root /var/www/wordpress; location ~ \.php(/|$) { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php-version-fpm.sock; } ssl_certificate /etc/ssl/local/service.pem; ssl_certificate_key /etc/ssl/local/service-key.pem; } It's very similar to Caddy's, except for the explicit cert. No professional should care about a handful of extra lines. Anyway, in many real life situations, the config will be long and complex, whatever tool you use. In the case above, the cert was created offline with the excellent mkcert from mkcert.dev, which is perfect for a developer machine. In other cases, I've had to use a certificate provided by my client. For the remaining cases, cerbot automates all, including nginx's config. Or if one installs the latest nginx, ACME cert retrieval is now included, so the difference to Caddy is shrinking. I don't deny that Caddy is a worthy tool, but I don't care if it makes me write a few lines less in configuration files that I rarely write or update. Praise should focus on more important features. [edit] The excellent leadership shown in this post seems more important!
  - christophilus 1y ago
    > except for the explicit cert That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.
    - rekoil 1y ago
      Right, in the nginx example above, someone has setup a secondary tool to provide certs at the location referenced, and is also handling renewal of them. Also, if I want to add another domain that should be accepted and reverse proxied to my application, in Caddy I just do this: example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } Suddenly not only does my Wordpress site respond on example.com, but also wp.example.com, and caddyfreakingrules.example.com, Caddy will fetch and automatically rotate certs for all three domains, and Caddy will auto-redirect from http to https on all three domains. (Does the ngnix example actually do that?) Another thing, does nginx with the above configuration automatically load new certs if the ones that were there when the process spawned have since expired? Because not only does Caddy automatically renew the certs, it is handled transparently and there's zero downtime (provided nothing changes about the DNS pointers of course). Caddy is freaking awesome! Bonus, if this were your Caddyfile (the entire thing, this is all that's needed!): { admin off auto_https prefer_wildcard email hostmaster@example.com cert_issuer acme { dir https://acme-v02.api.letsencrypt.org/directory resolvers 1.1.1.1 1.0.0.1 dns cloudflare {env.CLOUDFLARE_API_TOKEN} } ocsp_stapling off } example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } # This is simply to trigger generation of the wildcard cert without # responding with the Wordpress application on all of the domains. *.example.com { respond "This is not the app you're looking for" 404 } Then you'll disable the unauthenticated JSON API on localhost:2019 (which is a good security practice, this is my only gripe with Caddy, this API shouldn't be enabled by default), tell Caddy how to use the DNS-01 ACME resolver against Cloudflare (requires a plugin to Caddy, there are loads for many DNS providers), and then tell Caddy to use appropriate wildcard certs if it has generated them (which for *.example.com it will have). The result of which is that Caddy will only generate one cert for the above 3 sites, and Let's Encrypt won't leak the existance of the wp.example.com and caddyfreakingrules.example.com domains via certificate transparency.
- StopDisinfo910 1y ago
  It's also extremely nice as a reverse proxy. You get the certificate for free and defering authentication to a middleware is very easy. The community has some very good option for this like caddy-security.
relatall 1y ago
community management is hard, good luck

tln 1y ago

For me it's been 95% and 5%. Caddy is great!

queenkjuul 1y ago

Caddy rules, i can't imagine using anything else for the kind of projects I'm usually involved with.

kstrauser 1y ago

For those on the fence, imagine Nginx, but with all the defaults set to what you’d have them on in the first place. Here’s a complete configuration file for a Wordpress site with a LetsEncrypt TLS cert, static files, and PHP executed via FastCGI: example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } That’s it. That’s the whole thing. All the other settings are adjustable, but have the default values you’d configure yourself if you wanted to dig in and tweak it. I appreciate Caddy immensely. It doesn’t do anything Nginx can’t do, as far as I know, but it’s a whole lot more ergonomic while doing it.

3eb7988a1663 1y ago
Were the Nginx/Apache defaults bad at the time of creation? Has hardware changed? Security? Protocol versions? Which is to say, in N years, will the Caddy defaults be full of some unfortunate decisions? Caddy and Traefik have been around for a while now, so curious what has prevented the boring technology from essentially flipping some defaults around.
- francislavoie 1y ago
  IMO a big reason is simply because they're written in C, which greatly slows down progress due to having to write a lot more code to do the same thing as higher level languages, and having to take significantly more care about memory safety issues. Caddy and Traefik being written in Go inherently solves both those problems, in addition to being built on top of Go's fantastic http and crypto stdlib packages which does the vast majority of the heavy lifting for implementing a compliant server. The remainder is mostly the config layer and middleware/admin/compatibility pieces (oversimplifying of course) which is where we can spend all our focus, being freed from having to be concerned about protocol level stuff (for the most part). Admittedly there are some decisions we made with Caddy v2.0 that we would like to revisit eventually with a Caddy v3.0 in some future, but we haven't gotten to the point we've felt the need to plan that, most of those issues are minor enough that they haven't been deal-breakers. (And for context, v2.0 being a rewrite and rearchitecture from v0/v1 was necessary to unlock the potential that Caddy has realized today).
- kstrauser 1y ago
  A little bit of all the above. I had to spend a lot more time configuring Nginx to use the recommended TLS algorithms. Caddy also supports HTTP/2 and HTTP/3 by default, no config required. And those good defaults matter. If I pin down a set of TLS protocols today, will those still be good choices a couple of years from now? I don’t know. I’ll bet the then-current version of Caddy will still have good default settings. If HTTP/4 comes along, I suspect Caddy will configure it correctly on my site without me doing anything other than upgrading to a newer version, while other servers will want me to explicitly update their configs to enable it.
- noirscape 1y ago
  The main difference (as someone who is familiar with nginx and caddy, and whose Apache knowledge mostly comes from the era of "webapps are folders in your root with PHP files in them", so not very good) is that Nginx tends to be a very hands-off webserver. It doesn't do anything for you that the config files don't specify it should do. Of the three main ways to serve web content out there (static, CGI-esque aka PHP or a reverse proxy), nginx only really has a near config free experience (as in, your distro probably shipped a default config to make this work with zero effort) for serving static files - you just make a server block, a location block and point the root to the folder you want to serve. Setting up PHP or reverse proxies requires a lot more manual work; if you want X-Forwarded-* headers, you're gonna have to set those up for example. Similarly, nginx isn't going to be the one picking your SSL config out of the box; it's a bunch of arcane flags and settings (if you're not intimately familiar with SSL anyways) that you look up once how to get the SSLabs A+ score and then you put it in a reusable snippet to not have to think about that stuff ever again for future domains. If you want ACME certificates, you're gonna have to tell it to do that (nginx recently got a module for this I think, which kinda makes it equal in this sense to caddy's automatic LE cert generation) or where to find the certificates. Caddy automates a lot of this sort of thing; the result is smoother/cleaner config files (it's hard to deny that reverse_proxy is shorter than the several dozens of config lines you'd use for nginx) but you also need to be aware of what Caddy does by default and the assumption that what the Caddy developers think should be the default will also always be what you want, unless you want to poke at manual overrides (in which case it's pretty much nginx again.) It can also do a few common variants on static site hosting, like automatically pulling a git repo, running a page generator on it and serving the resulting folder, which nginx just straight up doesn't do afaik. In practice, I found Caddy works well on development/toy machines where there's no real expectations for having to think about prod and "not having to spend an hour reconfiguring your setup" when you start a project is beneficial and it's easy to swap things like ports around. Nginx works better on production machines because you basically set it up once and then can safely never have to think about it again, while still allowing you explicitly see why it's (not) doing what you want later down the line. Traefik I legitimately couldn't see a reason to use however. It's config syntax is atrocious and looking it up online tells me it's mainly popular with non-technical homelab people because it can serve a web UI to manage your reverse proxies in. I guess that's a desirable feature for some?
idoubtit 1y ago
I think this focus on the default configuration of Caddy is a poor incentive, in a professional context. Here is the same config for nginx on a Debian box: server { server_name example.com; root /var/www/wordpress; location ~ \.php(/|$) { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php-version-fpm.sock; } ssl_certificate /etc/ssl/local/service.pem; ssl_certificate_key /etc/ssl/local/service-key.pem; } It's very similar to Caddy's, except for the explicit cert. No professional should care about a handful of extra lines. Anyway, in many real life situations, the config will be long and complex, whatever tool you use. In the case above, the cert was created offline with the excellent mkcert from mkcert.dev, which is perfect for a developer machine. In other cases, I've had to use a certificate provided by my client. For the remaining cases, cerbot automates all, including nginx's config. Or if one installs the latest nginx, ACME cert retrieval is now included, so the difference to Caddy is shrinking. I don't deny that Caddy is a worthy tool, but I don't care if it makes me write a few lines less in configuration files that I rarely write or update. Praise should focus on more important features. [edit] The excellent leadership shown in this post seems more important!
- christophilus 1y ago
  > except for the explicit cert That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.
  - rekoil 1y ago
    Right, in the nginx example above, someone has setup a secondary tool to provide certs at the location referenced, and is also handling renewal of them. Also, if I want to add another domain that should be accepted and reverse proxied to my application, in Caddy I just do this: example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } Suddenly not only does my Wordpress site respond on example.com, but also wp.example.com, and caddyfreakingrules.example.com, Caddy will fetch and automatically rotate certs for all three domains, and Caddy will auto-redirect from http to https on all three domains. (Does the ngnix example actually do that?) Another thing, does nginx with the above configuration automatically load new certs if the ones that were there when the process spawned have since expired? Because not only does Caddy automatically renew the certs, it is handled transparently and there's zero downtime (provided nothing changes about the DNS pointers of course). Caddy is freaking awesome! Bonus, if this were your Caddyfile (the entire thing, this is all that's needed!): { admin off auto_https prefer_wildcard email hostmaster@example.com cert_issuer acme { dir https://acme-v02.api.letsencrypt.org/directory resolvers 1.1.1.1 1.0.0.1 dns cloudflare {env.CLOUDFLARE_API_TOKEN} } ocsp_stapling off } example.com wp.example.com caddyfreakingrules.example.com { root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server } # This is simply to trigger generation of the wildcard cert without # responding with the Wordpress application on all of the domains. *.example.com { respond "This is not the app you're looking for" 404 } Then you'll disable the unauthenticated JSON API on localhost:2019 (which is a good security practice, this is my only gripe with Caddy, this API shouldn't be enabled by default), tell Caddy how to use the DNS-01 ACME resolver against Cloudflare (requires a plugin to Caddy, there are loads for many DNS providers), and then tell Caddy to use appropriate wildcard certs if it has generated them (which for *.example.com it will have). The result of which is that Caddy will only generate one cert for the above 3 sites, and Let's Encrypt won't leak the existance of the wp.example.com and caddyfreakingrules.example.com domains via certificate transparency.
StopDisinfo910 1y ago
It's also extremely nice as a reverse proxy. You get the certificate for free and defering authentication to a middleware is very easy. The community has some very good option for this like caddy-security.

relatall 1y ago

community management is hard, good luck