Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Caddy 0.10 Released

caddyserver.com

Post reply on HN
Print view View original

111–120 of 128 posts

Re: Caddy 0.10 Released

#111

Post by Sphax »

mholt wrote: post #85
zzzcpan wrote: post #72

Earlier quoted context omitted.

No, not having timeouts is rather bad practice. There are a lot of clients out there that never close connections for various reasons. And since TCP doesn't use healthchecks and most systems by default have limits on the number of descriptors per process, your web server in default configuration will simply leak descriptors and memory over time until the whole thing stops working. The only sane choice here is to have…

Believe me, we wanted to do this, but it broke a lot of WebSocket connections and other legitimate, long-lived connections. It confused many users. It's hard to know what is legitimate and what is not. I wish we could configure timeouts on a per-request basis but not without some serious hacking around the net/http lib for now. I do encourage setting timeouts when you are able to. It's easy, for example: timeouts 30s…

Yeah, after an upgrade of Caddy on my server the syncthing ui broke. Not sure why but with timeouts the ui just doesn't work. It was a little surprising but I think it's more a problem syncthing should solve.

Re: Caddy 0.10 Released

#112

Post by drdaeman »

omginternets wrote: post #101
camus2 wrote: post #86

Earlier quoted context omitted.

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

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

Re: Caddy 0.10 Released

#113

Post by omginternets »

drdaeman wrote: post #112
omginternets wrote: post #101

Earlier quoted context omitted.

>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"…

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.

Re: Caddy 0.10 Released

#114

Post by eliaspro »

singlow wrote: post #29
blowski wrote: post #2

When would I use Caddy, rather than using nginx and configuring Let's Encrypt for myself? Honest question.

I use Nginx in production, but caddy on my dev machine, where I might have dozens of test sites running at any time. Those sites all live on subdomains of a dedicated dev domain and I rarely create more than 2 or 3 per week so I can always just use https with certificates generated on the fly. In Nginx I would need to constantly re-run certbot to add subdomains manually.

For all local/non-public instances I just use "tls self_signed" and have Caddy generate a cert on demand.

Re: Caddy 0.10 Released

#115

Post by Walkman »

mholt wrote: post #64
overcast wrote: post #16

So far I'm loving Caddy. Super simple to configure, and the auto management of SSL certificates is magical. However, for all of the simplicity, they are still pretty resistant to properly packaging it up in the repositories. By far the longest part of getting it running, is the stupid manual configuration of launch daemons, working directories, and permissions. For software that prides itself on dead simple managemen…

Of the 5 announcements we made yesterday, milestones for 0.11, 0.12, and 1.0 was one of them (and their details will be published to GitHub soon): one of the main purposes of 1.0 being stable is so that we can find ways to distribute Caddy better for people who want to use package managers. I know holding out isn't a popular decision but we really want to make sure we get it right given Caddy's unique needs with rega…

That's very nice to hear! I prefer this "make it great and release when it's perfect" attitude because it means way better quality and care I can rely on for the long term. Thanks for making Caddy, I'm pretty sure I will use it at one point!

Re: Caddy 0.10 Released

#116

Post by tyingq »

tlrobinson wrote: post #109
zufallsheld wrote: post #98

Earlier quoted context omitted.

At least with systemd caddy starts as a non-root user, if you use the provided unit-file: https://github.com/mholt/caddy/tree/master/dist/init/linux-s...

Is there something like `setcap` for macOS? Give the caddy binary the ability to bind to privileged ports (e.g. 80, 443) as a non-root user: sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

There isn't. There's a port of authbind, but I don't think anyone was able to get it working with caddy. The only solution I've heard of working is using the pf firewall to port forward, for example, 8080 to 80. Like this: https://salferrarello.com/mac-pfctl-port-forwarding/

Re: Caddy 0.10 Released

#117

Post by MichaelGG »

StreamBright wrote: post #105
StreamBright wrote: post #39

Earlier quoted context omitted.

2000 req/s is tragic. We have services with 100 000req/s so i need a reverse proxy with at least 500 000 req/s. What is the reason of this low performance?

I am not sure why this is getting downvoted, care to explain?

My guess: At 500Krps on a single proxy you're probably using 40GbE or higher right? So you're a fairly niche user and should have some sort of in-depth knowledge of this space. Your current setup should already some sort of horizontal scaling system in place. Just throwing out you "need" a 500Krps came across as fake boasting/clueless/whiny.

I'm sure HN would love a more in-depth comment where you say how you're accomplishing things today and what you expect out of general purpose reverse proxies, etc.

Re: Caddy 0.10 Released

#118

Post by pinoyyid »

pbreit wrote: post #71
sergiotapia wrote: post #36

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 mo…

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

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.

Re: Caddy 0.10 Released

#119

Post by [deleted] »

tlrobinson wrote: post #109
zufallsheld wrote: post #98

Earlier quoted context omitted.

At least with systemd caddy starts as a non-root user, if you use the provided unit-file: https://github.com/mholt/caddy/tree/master/dist/init/linux-s...

Is there something like `setcap` for macOS? Give the caddy binary the ability to bind to privileged ports (e.g. 80, 443) as a non-root user: sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/caddy

[deleted]

Re: Caddy 0.10 Released

#120

Post by jazoom »

tlrobinson wrote: post #93

Random question: is there a way to start Caddy as root so it can bind to port 80 (for example) then change the user so a non-root user can send a `USR1` signal to Caddy to get it to reload the configuration?

Yes. From their GitHub readme:

Running as root: We advise against this. You can still listen on ports < 1024 using setcap like so: sudo setcap cap_net_bind_service=+ep ./caddy

Post reply on HN