4 ms·

I know of several companies/organizations using Caddy in production; one instance in particular is serving tens of thousands of domains and managing their certi

by mholt 10y ago

I know of several companies/organizations using Caddy in production; one instance in particular is serving tens of thousands of domains and managing their certificates without difficulty. Netflix uses it for Vector (https://github.com/Netflix/vector/blob/6d013993fc1a5b2ae296f4fbaad476286a5eb36b/Dockerfile#L35 https://github.com/Netflix/vector/blob/6d013993fc1a5b2ae296f...), ChannelMeter uses it (https://channelmeter.com/ https://channelmeter.com/), and there are others. It seems that the biggest trouble that people have using Caddy in production is that there aren't official packages for installing/updating Caddy. Fortunately, it's a single, statically-compiled binary no matter how many plugins you choose, and downloading Caddy is as simple as a GET request. But I anticipate we will have some packages by version 1.0. (There's also this Docker image by abiosoft that has 100k+ pulls: https://hub.docker.com/r/abiosoft/caddy/ https://hub.docker.com/r/abiosoft/caddy/) Caddy is generally _easiest_ to use standalone and does fine for most people. Granted, it's not the right tool for everyone, but it's pretty good most of the time. Most of the troubles I've seen reported are in combination with Docker, faulty init system configurations, behind other proxies and load balancers, or trying to serve sites that don't have proper DNS resolution yet (which is required for auto HTTPS, which is on by default).

wanda 10y ago
> It seems that the biggest trouble that people have using Caddy in production is that there aren't official packages for installing/updating Caddy. Indeed. The closest thing is GetCaddy[1] which is far from ideal. I think if nginx were to get similarly simple Let's Encrypt integration, the case for using Caddy would become very niche. nginx is already easy to use and configure, and the only reason I recently switched to Caddy for my personal site, and a couple of smaller clients, was the time saved during server setup. [1] https://getcaddy.com https://getcaddy.com
- petre 10y ago
  Let's Encrypt is pretty easy to set up using lego on just about any HTTP server. I think Caddy uses it as well, at least go get pulls it from github when you attempt to build Caddy from source. Plus it's super easy to cross compile and deploy anywhere since, like Caddy, it's a single statically linked binary.
  - mholt 10y ago
    Fun fact: lego was originally commissioned for use in Caddy. Sebastian has done a great job with it!
- pfg 10y ago
  Another reason why someone might pick Caddy over nginx or apache is to get rid of OpenSSL (and forks). Go's TLS stack is generally considered to be one of the better TLS implementations out there. Despite not yet having received the same amount of attention as OpenSSL (which the authors acknowledge), the fact that it's (mostly) written in a safe(r) language and isn't as bloated as OpenSSL (which has many features that are completely irrelevant to the vast majority of TLS servers, but still cause vulnerabilities - see Heartbleed) would make me feel more comfortable with picking crypto/tls over OpenSSL.
- mholt 10y ago
  > I think if nginx were to get similarly simple Let's Encrypt integration, the case for using Caddy would become very niche. I hope to see this. If Caddy can inspire/motivate the really mainstream servers to add auto HTTPS, then a significant aspect of Caddy's mission would be a success. Caddy was fairly innovative on the auto HTTPS front. As interest in the project continues, I expect that we (the 100+ contributors) will keep making Caddy relevant. I'm really looking forward to the improved plugin system / build server and Caddy API to come together.

by mholt 10y ago

wanda 10y ago

> It seems that the biggest trouble that people have using Caddy in production is that there aren't official packages for installing/updating Caddy. Indeed. The closest thing is GetCaddy[1] which is far from ideal. I think if nginx were to get similarly simple Let's Encrypt integration, the case for using Caddy would become very niche. nginx is already easy to use and configure, and the only reason I recently switched to Caddy for my personal site, and a couple of smaller clients, was the time saved during server setup. [1] https://getcaddy.com https://getcaddy.com

petre 10y ago
Let's Encrypt is pretty easy to set up using lego on just about any HTTP server. I think Caddy uses it as well, at least go get pulls it from github when you attempt to build Caddy from source. Plus it's super easy to cross compile and deploy anywhere since, like Caddy, it's a single statically linked binary.
- mholt 10y ago
  Fun fact: lego was originally commissioned for use in Caddy. Sebastian has done a great job with it!
pfg 10y ago
Another reason why someone might pick Caddy over nginx or apache is to get rid of OpenSSL (and forks). Go's TLS stack is generally considered to be one of the better TLS implementations out there. Despite not yet having received the same amount of attention as OpenSSL (which the authors acknowledge), the fact that it's (mostly) written in a safe(r) language and isn't as bloated as OpenSSL (which has many features that are completely irrelevant to the vast majority of TLS servers, but still cause vulnerabilities - see Heartbleed) would make me feel more comfortable with picking crypto/tls over OpenSSL.
mholt 10y ago
> I think if nginx were to get similarly simple Let's Encrypt integration, the case for using Caddy would become very niche. I hope to see this. If Caddy can inspire/motivate the really mainstream servers to add auto HTTPS, then a significant aspect of Caddy's mission would be a success. Caddy was fairly innovative on the auto HTTPS front. As interest in the project continues, I expect that we (the 100+ contributors) will keep making Caddy relevant. I'm really looking forward to the improved plugin system / build server and Caddy API to come together.