Nginx is a superb piece of software but for me it has largely been superseded by Caddy. I like it for its sane defaults, you get most things working from the get go and a fairly high score on the 'rate your webserver security' checkers.
I seem to remember Caddy having some features behind a rather restrictive license - or something like that, my memory is failing me - that made me not consider it at all. But it's been a while, easily a handful of years, and looking at it right now, it looks like they changed that. Seems to be all open-source/Apache 2.0 licensed.
Am I crazy or did they really change the licensing situation? Cause it definitely looks pretty interesting, looking at current docs.
I sympathize a lot with the licensing story of Caddy. /u/mholt has been a very active maintainer and participant in the larger Go community and has every right to create a commercial side to the project and receive compensation for their work.
But licensing is hard. AWS abused the leniency of Elasticsearch's original OSS license, so now the industry is set back 10 years with new entrants trying to find the balance between inviting community participation and getting gob smacked by big corporate interests.
Im not saying Elastic.co is an angel but its a lesson OSS projects have to take to heart, unfortunately. Thanks Amazon.
I think my favorite reaction to Amazon's aggression is Grafana Labs. They released their code under Affero GPL but let you use a different license if you pay them. Sort of like a new version of the Qt model.
AGPL does nothing to protect commercial projects from AWS. Look at MongoDB: they had been AGPL for a loooong time, but moved to a non-FOSS license specifically because of AWS.
AWS has no problems with giving away the code for any managed-X service they. The magic that they charge for is the managed part - deployment, autoscaling, upgrade management, and other Operations stuff that no FOSS license can compel them to make public.
For a time we ran a build service that produced binaries that were commercially licensed if used for business purposes (personal use still free). But that was only with the optional use of our build service. The source code has always been Apache licensed.
Ah! So I guess it was just my junior dev mind that couldn't comprehend the nuances and didn't realize I could just use the open-source version rather than downloading binaries.
Thank you for the info, rather curious about trying it out at this point then. I was about to whip out nginx for a server I wanted to setup over the weekend, guess I'll play around with Caddy then!
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.
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.
> 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.
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.
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 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.
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.
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.
> 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. 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/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.
