4 ms·

> 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. Th

by 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 wanda 10y ago

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.