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

21–30 of 128 posts

Re: Caddy 0.10 Released

#21

Post by bauerd »

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…

>the basics of getting it into a package manager should not even be a discussion.

Last time I looked into it, their problem was that Caddy plugins must be configured at compile-time, because runtime plugins seem to be hard to do with Golang (besides RPC). Because there's a handful of Caddy plugins, they'd either have to provide a slim package with no plugins, or ship with all or only some blessed plugins. Obviously all approaches have drawbacks … they discussed the option of shipping their own package manager for Caddy plugins, too (shudder).

See: https://forum.caddyserver.com/t/packaging-caddy/61

Re: Caddy 0.10 Released

#22

Post by coldtea »

shawabawa3 wrote: post #11
blowski wrote: post #7

Earlier quoted context omitted.

What's the performance like? Can you use it as a proxy server?

I use it exclusively as a proxy server. I've never noticed any performance issues, I think I saw a benchmark where it said caddy can handle 2000req/s, which is at least an order of magnitude or 2 faster than any upstream service I've used it in front of.

>I think I saw a benchmark where it said caddy can handle 2000req/s

Those are application level numbers (e.g. with logic and all).

Caddy should be able to handle an order of magnitude more req/s than that easily.

Re: Caddy 0.10 Released

#23

Post by Sphax »

xiphias wrote: post #6
knrz wrote: post #3

Earlier quoted context omitted.

I feel like the niche Caddy's trying to fill is for people who don't want to bother with that, or don't want to learn. If you already know how to set up nginx and LE (like you and I do), its only appeal is relatively minor: potentially saving a quarter or half hour.

I think over time there will be a similar server written in Rust, where at least we can be sure that there are no buffer overflows..until then nginx is probably better in every situation.

Do we really need someone to mention Rust in every thread ?

Re: Caddy 0.10 Released

#24

Post by coldtea »

xiphias wrote: post #6
knrz wrote: post #3

Earlier quoted context omitted.

I feel like the niche Caddy's trying to fill is for people who don't want to bother with that, or don't want to learn. If you already know how to set up nginx and LE (like you and I do), its only appeal is relatively minor: potentially saving a quarter or half hour.

I think over time there will be a similar server written in Rust, where at least we can be sure that there are no buffer overflows..until then nginx is probably better in every situation.

Unless it uses unsafe code (which Rust also provides) Caddy wouldn't have buffer overflows either, since Go is garbage collected and doesn't allow for the kind of pointer arithmetic C does in normal code.

Re: Caddy 0.10 Released

#25

Post by singlow »

bauerd wrote: post #21
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…

>the basics of getting it into a package manager should not even be a discussion. Last time I looked into it, their problem was that Caddy plugins must be configured at compile-time, because runtime plugins seem to be hard to do with Golang (besides RPC). Because there's a handful of Caddy plugins, they'd either have to provide a slim package with no plugins, or ship with all or only some blessed plugins. Obviously a…

Nginx had the same issue. Ubuntu ships 3 or 4 versions - nginx-light, nginx, nginx-full, nginx-extras - for different numbers of modules included.

Re: Caddy 0.10 Released

#26

Post by dozzie »

bauerd wrote: post #21
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…

>the basics of getting it into a package manager should not even be a discussion. Last time I looked into it, their problem was that Caddy plugins must be configured at compile-time, because runtime plugins seem to be hard to do with Golang (besides RPC). Because there's a handful of Caddy plugins, they'd either have to provide a slim package with no plugins, or ship with all or only some blessed plugins. Obviously a…

> [...] their problem was that Caddy plugins must be configured at compile-time, because runtime plugins seem to be hard to do with Golang [...] they'd either have to provide a slim package with no plugins, or ship with all or only some blessed plugins.

Or ship the source in the package and build the target binary in the post-install. Or do what Debian does with Exim and nginx: provide several packages, each with different set of plugins compiled in. And these are just ideas from top of my head.

Re: Caddy 0.10 Released

#27

Post by atonse »

knrz wrote: post #3
blowski wrote: post #2

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

I feel like the niche Caddy's trying to fill is for people who don't want to bother with that, or don't want to learn. If you already know how to set up nginx and LE (like you and I do), its only appeal is relatively minor: potentially saving a quarter or half hour.

The appeal is huge for a huge number of people. It's an opinionated web server. I've used nginx for probably 6-7 years, and not once have I done something I'd consider that special (I've setup fpm, passenger, gzipping of content, TLS, regenerating my DH param, etc).

Every single thing I've done, could be implemented in an opinionated away by the web server. I'd love to just say "php" and have it do the right thing.

In fact, I'd go as far as to say, it would be amazing if I could just say "proxy ____ drupal" instead of php, and it'll add the drupal rules as well.

Re: Caddy 0.10 Released

#28

Post by anaganisk »

Sphax wrote: post #23
xiphias wrote: post #6

Earlier quoted context omitted.

I think over time there will be a similar server written in Rust, where at least we can be sure that there are no buffer overflows..until then nginx is probably better in every situation.

Do we really need someone to mention Rust in every thread ?

someone had to say it :p

Re: Caddy 0.10 Released

#29

Post by singlow »

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.

Re: Caddy 0.10 Released

#30

Post by vosper »

lol768 wrote: post #8

The MitM detection is interesting. How long until these appliances start altering the HTTP request's User-Agent header to avoid detection (or adding logic such that the handshaking process mimics that of the browser), though? To me, HPKP with preloading seems like a more reliable approach (and browsers shouldn't allow this to be overridden [1]). [1] If this breaks corporate MitM attacks, great. This practice always s…

I'd also be concerned if an employer was doing it, unless there was a good reason - and I can think of a few of those. For example, companies that deal with sensitive health, financial or legal information. They may need assurances (or at least a paper trail) that's a lot stronger than "we don't MITM and we trust our employees to do the right thing".
Post reply on HN