3 ms·

For me personally the problem with Caddy is growth and community guides/resources. Caddyfile is pretty basic, anything advanced doesn't work, and community res

For me personally the problem with Caddy is growth and community guides/resources. Caddyfile is pretty basic, anything advanced doesn't work, and community resources arent even close to Nginx. So I stick with nginx, even though its annoying to handle Let's encrypt auto renew in containers with normal Nginx, since SWAG doesn't support separate certificates per domain.

francislavoie 4y ago
> Caddyfile is pretty basic, anything advanced doesn't work I disagree. I think we're at about 95%-ish of usecases supported by the Caddyfile. We're continually improving on this. It's just a reality of having to maintain a config adapter, when the actual underlying config at runtime is JSON. But it's fine, we make it work :) If you have something specific you find you can't do with the Caddyfile, please open an issue. If you're just not sure, please open a topic on our community forums and we'll help you out.
- Shorel 4y ago
  The most complex thing I remember doing with nginx is video streaming using OBS as a source and multiplexing with nginx to YouTube, Facebook and Twitch. How can I do this with Caddy?
  - francislavoie 4y ago
    Well, that's a bit off-topic from the parent comment, which was more about the Caddyfile supporting complex config (versus the underlying JSON config) and not really "complex usecases". But that said, from a quick Google search... was this an RTMP stream? If so, I suppose you'd want to use https://github.com/mholt/caddy-l4 https://github.com/mholt/caddy-l4 which is a plugin for Caddy that lets you do TCP-layer things. Caddy's standard distribution just ships an HTTP server (plus TLS and PKI, etc), which is layer-7 You might be able to use caddy-l4's "tee" handler to pipe into multiple "proxy" handlers. But I'm not sure anyone's tried this yet, I had no idea people did this sort of thing. I'd be interested to hear if it does work though.
mholt 4y ago
What do you mean by "growth" being a problem? (If you're talking about scale, we have companies with tens of thousands of sites behind their Caddy instances.) > anything advanced doesn't work, Can you be more specific? I'm sure that's not true because I'm in touch with large companies like Stripe who use some of the most advanced features.
- jacooper 4y ago
  Growth as in advancing knowledge in the program and not hitting a limit where you have to switch to another one and start from zero. I didn't find a better word for it, I'm not an English native.
dizhn 4y ago
Their one major disadvantage is the chasm between version 1 and 2. Most info you can find is about version 1 and does not apply to version 2. I don't like its community much either. The top guys are pretty arrogant. You can meet them in discord. They spent months trying to get away from adding forward proxy support claiming another project provided support for it. (That project changed three times in that time frame) Now they added the feature like somebody just asked for it and they added it.
- BrandoElFollito 4y ago
  I do not know who the "top guys" are but support from Matt and Francis has been extraordinary for me. When starting with Caddy (v1) I missed part of the docs and asked questions in the community - I never got a RTFM answer. It is difficult to embrace a new product and these guys understand it. The Go community, on the other hand... :)
  - mholt 4y ago
    We try to be helpful :D Thank you for the kind remarks and for being part of our community!
- francislavoie 4y ago
  > They spent months trying to get away from adding forward proxy support claiming another project provided support for it. That is not what happened. We did not understand what people were asking for at the time, partly because it wasn't clearly explained to us. > Now they added the feature like somebody just asked for it and they added it. It being added recently was because of other changes to the codebase that made it possible to implement easily. We didn't have response intercepting working correctly in the reverse_proxy module until more recently, and it took some careful refactors to get it right. Once we were made aware of an issue in Authelia's issue tracker (one of the top open source auth servers) asking for Caddy support, we looked into it more closely. Nobody reached out to us about that issue being open, for whatever reason. We got a massive amount of help from James Elliott at Authelia who did extensive testing and helped us design the config layer so that it would match general expectations. The issue I think you're talking about is this one: https://github.com/caddyserver/caddy/issues/2894 https://github.com/caddyserver/caddy/issues/2894. Early on in v2 betas, we opened the discussion to get community feedback about the "Authenticator" interface, i.e. https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/caddyauth/caddyauth.go#L100-L106 https://github.com/caddyserver/caddy/blob/master/modules/cad... and what would be needed to support everyone's needs. Nobody ever suggested "forward auth" in that issue. It was all very handwavey suggestions with nothing truly actionable. So the discussion stagnated, and we closed the issue. > Their one major disadvantage is the chasm between version 1 and 2. Most info you can find is about version 1 and does not apply to version 2. Caddy v2's been out for 2.5 years now. I think the balance has shifted on this, it's much easier to find info for v2 than some time ago. That came naturally. It's to be expected for _any_ major change in a project's direction. It's not unique to Caddy in any way. > I don't like its community much either. The top guys are pretty arrogant. With all the above said, I think it's moreso that we feel the need to defend Caddy and its reputation, especially because it keeps getting attacked due to misinformed comments, for example the question of licensing; the licensing issue people had was mostly invented based on a misunderstanding. But feel free to elaborate on what you think we're being "arrogant" about. I'd be glad to clarify any misunderstandings.

francislavoie 4y ago

> Caddyfile is pretty basic, anything advanced doesn't work I disagree. I think we're at about 95%-ish of usecases supported by the Caddyfile. We're continually improving on this. It's just a reality of having to maintain a config adapter, when the actual underlying config at runtime is JSON. But it's fine, we make it work :) If you have something specific you find you can't do with the Caddyfile, please open an issue. If you're just not sure, please open a topic on our community forums and we'll help you out.

Shorel 4y ago
The most complex thing I remember doing with nginx is video streaming using OBS as a source and multiplexing with nginx to YouTube, Facebook and Twitch. How can I do this with Caddy?
- francislavoie 4y ago
  Well, that's a bit off-topic from the parent comment, which was more about the Caddyfile supporting complex config (versus the underlying JSON config) and not really "complex usecases". But that said, from a quick Google search... was this an RTMP stream? If so, I suppose you'd want to use https://github.com/mholt/caddy-l4 https://github.com/mholt/caddy-l4 which is a plugin for Caddy that lets you do TCP-layer things. Caddy's standard distribution just ships an HTTP server (plus TLS and PKI, etc), which is layer-7 You might be able to use caddy-l4's "tee" handler to pipe into multiple "proxy" handlers. But I'm not sure anyone's tried this yet, I had no idea people did this sort of thing. I'd be interested to hear if it does work though.

mholt 4y ago

What do you mean by "growth" being a problem? (If you're talking about scale, we have companies with tens of thousands of sites behind their Caddy instances.) > anything advanced doesn't work, Can you be more specific? I'm sure that's not true because I'm in touch with large companies like Stripe who use some of the most advanced features.

jacooper 4y ago
Growth as in advancing knowledge in the program and not hitting a limit where you have to switch to another one and start from zero. I didn't find a better word for it, I'm not an English native.

dizhn 4y ago

Their one major disadvantage is the chasm between version 1 and 2. Most info you can find is about version 1 and does not apply to version 2. I don't like its community much either. The top guys are pretty arrogant. You can meet them in discord. They spent months trying to get away from adding forward proxy support claiming another project provided support for it. (That project changed three times in that time frame) Now they added the feature like somebody just asked for it and they added it.

BrandoElFollito 4y ago
I do not know who the "top guys" are but support from Matt and Francis has been extraordinary for me. When starting with Caddy (v1) I missed part of the docs and asked questions in the community - I never got a RTFM answer. It is difficult to embrace a new product and these guys understand it. The Go community, on the other hand... :)
- mholt 4y ago
  We try to be helpful :D Thank you for the kind remarks and for being part of our community!
francislavoie 4y ago
> They spent months trying to get away from adding forward proxy support claiming another project provided support for it. That is not what happened. We did not understand what people were asking for at the time, partly because it wasn't clearly explained to us. > Now they added the feature like somebody just asked for it and they added it. It being added recently was because of other changes to the codebase that made it possible to implement easily. We didn't have response intercepting working correctly in the reverse_proxy module until more recently, and it took some careful refactors to get it right. Once we were made aware of an issue in Authelia's issue tracker (one of the top open source auth servers) asking for Caddy support, we looked into it more closely. Nobody reached out to us about that issue being open, for whatever reason. We got a massive amount of help from James Elliott at Authelia who did extensive testing and helped us design the config layer so that it would match general expectations. The issue I think you're talking about is this one: https://github.com/caddyserver/caddy/issues/2894 https://github.com/caddyserver/caddy/issues/2894. Early on in v2 betas, we opened the discussion to get community feedback about the "Authenticator" interface, i.e. https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/caddyauth/caddyauth.go#L100-L106 https://github.com/caddyserver/caddy/blob/master/modules/cad... and what would be needed to support everyone's needs. Nobody ever suggested "forward auth" in that issue. It was all very handwavey suggestions with nothing truly actionable. So the discussion stagnated, and we closed the issue. > Their one major disadvantage is the chasm between version 1 and 2. Most info you can find is about version 1 and does not apply to version 2. Caddy v2's been out for 2.5 years now. I think the balance has shifted on this, it's much easier to find info for v2 than some time ago. That came naturally. It's to be expected for _any_ major change in a project's direction. It's not unique to Caddy in any way. > I don't like its community much either. The top guys are pretty arrogant. With all the above said, I think it's moreso that we feel the need to defend Caddy and its reputation, especially because it keeps getting attacked due to misinformed comments, for example the question of licensing; the licensing issue people had was mostly invented based on a misunderstanding. But feel free to elaborate on what you think we're being "arrogant" about. I'd be glad to clarify any misunderstandings.