Hacker News Reader

Comment by giancarlostoro | Hacker News Reader

So Caddy has been discussed a few times prior. My question is who is using this for production? (In other words, not for a personal or hobby site, but an actual product). Is anyone using it stand alone (no nginx or apache involved - CloudFlare is ok edit: or similar), sorry if it was asked in a previous discussion I want to know if anything has changed since.

View on HN

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/6d013993fc1a5b2ae296f...), ChannelMeter uses it (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/)

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

> 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

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.

Fun fact: lego was originally commissioned for use in Caddy. Sebastian has done a great job with it!

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.

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

We use it on https://hsreplay.net, which serves about 100-200k requests / day behind Cloudflare.

Pros: It's super useful not to have to worry about HTTPS renewal. The caddyfiles are super simple. The Caddy code is beautiful to read and simple to understand. The plugin system is great.

Cons: At load, we got bitten hard by the default proxy timeout behaviour. That particular issue has been fixed in 0.9.3 (fail_timeout).

Haven't had any other issues, but it does feel pretty stressful to run unproven software in prod. Thankfully, we can easily switch back to nginx if we need to.

Thank you for helping to prove it in production!

And thank you for writing it! It's a great initiative.

I switched https://iwl.me to it from nginx a few months ago and I'm very happy so far. I use it as a proxy for a Go app server and also to serve static files.

Can you explain the problems you had with nginx that prompted you to migrate? Http/2 and Https?

No particular problems, just wanted something simpler and written in a memory-safe language.

Oh, and of course, automatic certificate renewal without configuring certbot.

It was briefly used by MELPA [0] but they moved back to nginx. Performance, load appeared to be the driving reasons. (See their issue tracker for a bit of history.)

[0] https://melpa.org/

Gopher Academy and golang news use Caddy (if they count) according to this:

https://golangnews.com/stories/43

We're using Caddy in production. It's working quite well so far. It's a really smart helpful project.

I'd recommend reading the documentation. We had a nasty surprise when Caddy decided all our backend servers were broken and it removed them. After that we stopped naively running the proxy with the default settings. https://caddyserver.com/docs/proxy

We changed the default proxy failover behavior in 0.9.3. You now have to opt-in to failure handling by specifying the behavior you want. See https://github.com/mholt/caddy/pull/1135 for more details.

I've been using it on several sites for over a year as a simple reverse proxy with lets encrypt built in. Resource usage is low and performance is good, certainly good enough for ~95% of websites which are low to med traffic. Here is one example in production:

https://golangnews.com

It's a patchwork of different Go libraries, Caddy doesn't implement anything itself like Apache or Nginx would. It's useful but certainly not "proved" in a production environment. The heck you don't need Caddy if you are already using Go to develop servers, just use the libraries it uses directly.

Do you really need a throwaway account to make a comment?

I think there's a certain subset of people that like to read HN but not submit/comment, either for reasons of anonymity or just because they don't want to. They may be inclined to comment from time to time, and create a temp account to do so, since HN does not allow anonymity. Also, it's possible they had an account that was banned/shadow banned, and refuse to make another full account out of protest.

That is, this may not be someone using a throwaway account in lieu of their real account, but because they don't have a real account to use.

It's funny how when they ask you if you really have to be anonymous it tips the scales towards "yes".

It is simply not true that caddy is JUST a collection of Go libraries, since parts of it like the Caddyfile concept are developed by Matt Holt, the (main) dev behind Caddy. Apart from that I would definetly say that Caddy is far easier to use than Apache or Nginx, which is a big bonus if you are just getting started in web development.

> It's a patchwork of different Go libraries, Caddy doesn't implement anything itself

If that were true (I'm not expert but I don't believe it to be the case), why would it be a problem? If it implements what people want efficiently enough and securely it shouldn't matter that it isn't written from scratch. Yes, anyone can tie libraries together, but if you are trying to work on something else you might not want to spend time doing that and resolving all the edge cases that you'll run into along the way.

> like Apache or Nginx would.

Apache started life as a huge collection of patches onto something else rather then implementing everything itself, and many would argue that this history still shows in negative ways at times.

Apache is a great project, but it really isn't a good example to use when trying to make the case for implementing everything in-project as efficiently as possible instead of using external dependencies.

> It's useful but certainly not "proved" in a production environment.

Some have already indicated otherwise on this thread.

Though as it hasn't been around all that long and has relativity recently seen significant internal changes so I'll grant that if you are being very careful you might not consider it mature/refined/proven enough for some production environments.

> if you are already using Go to develop servers, just use the libraries it uses directly.

IF you are already using Go. Many people aren't. I for one don't.

IF it were true (which I don't think it is) that it just strings libraries together

IF it didn't detract from your other ("not writing a http* proxy" based) project goals; because it took zero time & effort to put those libraries together and test & support the arrangement going forward, dealing with changes to said libraries over time, edge cases in their interactions, new and interesting problems in the wild due to odd client applications and proxies connecting to it, ...

I don't use Caddy yet (I have experimented with it and when time permits it will probably become part of my infrastructure at some point soon) so I have no particular axe to grind in support of it (other than it looks useful for my use case due to the relatively hassle free config and automatic LE certificate processing), but your argument against using it is at best flimsy.

Of course you may have registered a throwaway account in order to just troll a bit and get reactions; in which case good show sir, you appear to have achieved your goal!

Apache started life as a huge collection of patches onto something else rather then implementing everything itself, and many would argue that this history still shows in negative ways at times. Apache is a great project, but it really isn't a good example to use when trying to make the case for implementing everything in-project as efficiently as possible instead of using external dependencies.

That's not quite true. Maybe you are confused about the "module" aspect of Apache httpd and what it really means. Sure, there are a bunch of external, 3rd party modules, but the bulk of Apache capability is handled by bundled, official, "in-project" modules and not external dependencies.

> Maybe you are confused about the "module" aspect of Apache httpd and what it really means

No, I'm referring to Aapche originally starting life as a series of patches to the code for the NCSA HTTPd server and related libraries - stringing together existing code rather than being a fresh new implementation as implied by the comment replied to.

I used it in prod for couple of months, then all of a sudden it stopped working, could not figure out how to fix it since there is not so much information on the web.

Removed and installed latest nginx. In my opinion it's not prod-ready.

Reply on news.ycombinator.com