I'd rather use something that can be packaged and maintained properly by distributions: https://repology.org/project/caddy/versions I use distributions because I care about security and I'll be downvoted to oblivion for saying this.
Yeah, if you're looking for a package, you'll want to stick to the Cloudsmith .deb since it's bound to Caddy's GitHub release workflow so guaranteed to stay up-to-date: https://cloudsmith.io/~caddy/repos/stable/packages/ P.S., from the guidelines: > Please don't comment about the voting on comments. It never does any good, and it makes boring reading. edit: and an official response https://news.ycombinator.com/item?i…
Show HN: Caddy v2.5.0
71–80 of 115 posts
Re: Show HN: Caddy v2.5.0
#72Re: Show HN: Caddy v2.5.0
#73Caddy is such a delight! I can't reccomend it fast enough when somebody mentions they are on nginx. Small random feedback: I like the idea of JSON configuration but most of the common docs/recipes are documented only with the Caddyfile format. I couldn't figure out the full JSON schema that was expected so I wound up generating a Caddyfile string instead for my programatic control. Maybe there is some translation too…
I'm a heavy nginx user - there's not much that I haven't already done with it and I know the documentation quite well. Why would someone like me change to Caddy? I can see there are some NGINX Plus features that are free in Caddy.
The real reason is the thing you highlighted: "I can see there are some NGINX Plus features that are free in Caddy." Sadly it seems that NGINX is now crippleware. Personally I find it risky to depend on open source organizations who refuse to accept important features to the project, so they can sell those features as proprietary.
Re: Show HN: Caddy v2.5.0
#74The Dynamic Upstreams feature looks good, but it doesn't seem to be as nicely integrated with Consul as Traefik is.
Could you elaborate on what you mean? For now we only ship with support for SRV and A/AAAA, but anyone can write a Consul implementation if they like. I'm not sure how that would differ from SRV though, since Consul supports SRV anyways. I'm not a Consul user though.
"Note that DNS is limited in size per request, even when performing DNS TCP queries.
For services having many instances (more than 500), it might not be possible to retrieve the complete list of instances for the service.
When DNS SRV response are sent, order is randomized, but weights are not taken into account. In the case of truncation different clients using weighted SRV responses will have partial and inconsistent views of instances weights so the request distribution could be skewed from the intended weights. In that case, it is recommended to use the HTTP API to retrieve the list of nodes."
[1] https://www.consul.io/docs/discovery/dns#service-lookups
Re: Show HN: Caddy v2.5.0
#75Earlier quoted context omitted.
Could you elaborate on what you mean? For now we only ship with support for SRV and A/AAAA, but anyone can write a Consul implementation if they like. I'm not sure how that would differ from SRV though, since Consul supports SRV anyways. I'm not a Consul user though.
Quoting the Consul docs [1]: "Note that DNS is limited in size per request, even when performing DNS TCP queries. For services having many instances (more than 500), it might not be possible to retrieve the complete list of instances for the service. When DNS SRV response are sent, order is randomized, but weights are not taken into account. In the case of truncation different clients using weighted SRV responses wil…
I'll say that it's unlikely we'll work on this unless a sponsor funds the development. The dynamic upstreams feature was funded by a sponsor requiring improved SRV support (we did have SRV support before v2.5.0, but it was rudimentary and insufficient for many usecases).
If someone needs this and can spend some time developing it, essentially it's just a module which implements this interface: https://pkg.go.dev/github.com/caddyserver/caddy/v2/modules/c...
Re: Show HN: Caddy v2.5.0
#76Re: Show HN: Caddy v2.5.0
#77I wish Caddy went all in on the caddyfile and dumped the JSON. The meagre examples are split between the two formats, it’s tough trying to figure out how to do something that’s not straightforward. Even worse when you find out some config isn’t supported by caddyfile and have to export to a giant JSON mess, I look at the result and think this is not what I signed up for.
Re: Show HN: Caddy v2.5.0
#78But that JSON config file?
It’s a mistake. And I’m Being charitable and nice here.
Especially the part where there is an api to update the JSON file.
Jesus Christ Matt. Just use the caddyfile already. It’s easy, easy to read by everyone. Why make a config file hard to grok or follow by multiple team members?
I don’t get that part.
Re: Show HN: Caddy v2.5.0
#79Caddy is absolutely amazing. I'm running it on an RPi that's hosting various home automation and hobby projects, all serving HTTP to the loopback interface only, with Caddy acting as a reverse proxy, and I've never even had to think about HTTPS. Adding a new service is adding a single line to my config file, and the rest happens automatically. Finally, no more "trust this self-signed certificate" even for toy project…
Setting that up with nginx and acme.sh is pretty easy as well. One benefit I found with using nginx is that services are more likely to have nginx proxy example configs, and sometimes these are non-trivial, eg.: https://docs.mattermost.com/install/config-proxy-nginx.html I guess with caddy you're on your own, which doesn't look like fun.
sub.domain.com { reverse_proxy localhost:8080 }
Re: Show HN: Caddy v2.5.0
#80Love caddy. We use it 100% on a whole bunch of servers and products. It’s the only tool that can do what it does. But that JSON config file? It’s a mistake. And I’m Being charitable and nice here. Especially the part where there is an api to update the JSON file. Jesus Christ Matt. Just use the caddyfile already. It’s easy, easy to read by everyone. Why make a config file hard to grok or follow by multiple team membe…