Hacker News Reader

Hacker News

Comment by sergiotapia | Hacker News Reader

Full thread

sergiotapia

Caddy is a web server written entirely in Go.

Features:

- Easy configuration with Caddyfile

- Automatic HTTPS via Let's Encrypt; Caddy obtains and manages all cryptographic assets for you

- HTTP/2 enabled by default (powered by Go standard library)

- Virtual hosting for hundreds of sites per server instance, including TLS SNI

- Experimental QUIC support for those that like speed TLS session ticket key rotation for more secure connections

- Brilliant extensibility so Caddy can be customized for your needs

- Runs anywhere with no external dependencies (not even libc)

View on HN

Are you sure it doesn't even depend on libc? Most Go programs do end up depending on libc by default; they have to be specially compiled to avoid the libc dep (IIRC, anything that depends on net or net/http or something of that sort).

Go ships with both a pure Go and a libc-based DNS resolver. Some systems (like OS X) don't let Go make DNS requests directly. For more see https://golang.org/pkg/net/#hdr-Name_Resolution

> Some systems (like OS X) don't let Go make DNS requests directly.

I don't think this is a reasonable summary of the situation on OS X. That being that if you turn the firewall on and then turn on block of incoming connections on 10.11 and earlier, responses seem to get dropped. Characterizing that as a blanket disallowing of direct DNS requests is misleading. (I'm not defending OS X here, it's just that summaries like this turn into cargo cults.)

So is it ready for "prime time"? Should I be considering it over Nginx for side projects or real projects?

Absolutely use it for side projects! I have used it for a lot of small throw-away sites and loved every minute.

It's up to you whether you trust it for large products, but so far it has been fairly magical for me.

I asked this question yesterday. People ask if it's "production ready" but that's like asking if something is "secure" -- I don't really know what that means. Many people use Caddy in production; it's also great for local development. People use it for "real" projects. (I do.) If it is a good match for your needs, give it a try! Start small if you're nervous, but you'll probably like it.

> but that's like asking if something is "secure"

no, that's asking if an enterprise grade project is fronted with Caddy.

> People use it for "real" projects. (I do.)

Sure, but you're not Facebook, Google or Oracle, or big brand X or Z. If you can get Coca Cola, or Nike website run on Caddy, it will change that perception.

Caddy uses go's standard libraries for most of its web serving parts, so you know at least that the http server code is used by google, cloudflare etc. Same goes for SSL and many other parts.

However most companies out there aren't Facebook, Google, Oracle, Coca Cola or Nike anyway.

Using Go standard HTTP libraries doesn't guarantee things are stable.

Here's an example how a missing option (that is Go 1.8+ - which is a recent release) can lead to a DoS: https://github.com/containous/traefik/issues/1322

Yeah, as it happens in software in general there aren't any guarantees. I could too give you a link to heartbleed. Caddy wasn't affected.

Well, yes, although security and stability are different matters. Every software has bugs, I just said that the fact something is using Go HTTP library doesn't automagically mean it's production quality. There are always many ways to accidentally shot oneself in the leg.

(Caddy, in my experience is production quality. I've used it in a few projects and haven't had any serious issues. Maybe that's just my use cases, though.)

Stability is relative. Knowing that it uses standard Go networking libs is an indication of how stable this thing is.

>no, that's asking if an enterprise grade project is fronted with Caddy.

Just because you'll be the first to use something for some purpose doesn't make the tool unfit for said purpose.

The parent post's point stands: "production-ready", like "secure", is a highly relative term.

I think I'd disagree.

While Caddy doesn't do that, production readiness is something that can be objectively measured. Define some metric, like "how many % users encounter stability-related issues/error conditions", throw in telemetry and there will be solid numbers. Many do that with their own software deployments, using Sentry or similar solutions, deciding on whenever their beta deployments are "production ready" or "not yet". Of course, that only works with a large enough user base, otherwise the error margins are too high for the number to be any meaningful. It is relative only in regard whenever, say, "0.01% (just a random number) of users have encountered severe issues" is "way too many" or "oh, it's just a few".

Security, on the other hand, is a different beast. Formal proofs aside - trying to define some similar metric "how many installations were hacked" or "how many security issues were found" isn't really meaningful.

But I think it would be really off-topic. =/

You're missing my point, I think. What you're describing is an epistemological problem, i.e.: "how do I know this thing is production ready?". This problem is (mostly) independent of whether or not the thing actually is production-ready.

The point is that knowing about previous use in production is one way of knowing to what extent something is production-ready. There are other ways (e.g.: well-controlled tests).

As for your point about security, I couldn't disagree more strongly. Comparing histories of compromises and mitigations across various projects is, in practice, a very useful metric. See OpenBSD for an example.

Yes, it's pretty nice and sometimes is even nicer than nginx in some regards. E.g. it notices DNS changes without SIGHUP, so if your app is containerized, Caddy just works when you start and stop containers, when nginx requires special tricks.

However, it lacks in some areas, for example if you need some complex regex-based routing it could be somewhat unpleasant (while probably doable, the configs would look really messy).

Wait... why would a web server need to know about changing DNS?

It doesn't need to know about the changes, but it surely needs to notice them as they happen.

For example, FLOSS nginx does DNS lookups just once on startup. On config (re)loads, to be exact.

E.g. when you have "proxy_pass http://spam;" or "uwsgi_pass spam:9000;", you'll end up with permanent 502 (until a SIGHUP) after you've started a new "spam" Docker container and then removed the old one.

There are well-known workarounds like "set $backend "http://spam"; proxy_pass $backend;", but it's nicer when you don't even have to think about this and know that TTLs are properly honored. Caddy does that.

> Caddy just works when you start and stop containers

That doesn't sound great for zero downtime deployment but

> notices DNS changes

That sounds like it could support zero downtime (new container started, DNS records updated to this new container and then stopping old container).

Is this something like DNS SRV support in Nginx Plus? [0]

[0]: https://www.nginx.com/blog/service-discovery-nginx-plus-srv-...

imho - no

Unlike Apache which served me well for 14 years without failure or interruption, I've had 3 hours of downtime in 2 months with Caddy. I haven't dug into the code, and I don't know Go, but my sense is that it needs to do much better at compartmentalising and isolating failures, and providing meaningful diagnostics for things like configuration errors.

Two specific examples:-

- If caddy can't obtain SSL certs for a configured domain, it completely fails to load. As an ops guy, I don't want 5 virtual hosts down because of a problem with a sixth, non-critical domain.

- A missing "}" in my Caddyfile caused a load failure with a message "invalid email address". Took me 30 minutes to find the problem. An error saying "Missing } in Caddyfile" would have far more helpful.

The project has great promise, but from an ops perspective, you'd be pretty bonkers to prefer Caddy over the more mature alternatives.

Reply on news.ycombinator.com