I think its because nginx was (and for most, still is) generational [compared to apache] in terms of core features and ease of configuration. I can see how caddy would be the next alternative though: more – "modern" if you may – features (money quote: built-in letsencrypt) but more importantly even simpler configuration.
edit: This is also where your use case makes it easy to see why nginx (or caddy) won't cut it.
Neat, thanks for mentioning Caddy [0]. I hadn't heard about it before now, and just from looking over their docs it looks very promising.
Their website is superb, with simple explanations of what the tool does and transparent pricing for their paid options.
The only thing I'm initially a tiny bit weary about is their claim of it being production ready. Being used by thousands of sites is an amazing feat, but how big are the loads on these sites? Production-ready can mean completely different things depending on what you're building. I think it'd be a nice improvement to see a bit more data backing up that claim. Just from a quick google search it looks like there's a decent number of articles comparing it with nginx, so I guess I"ll stat digging in a bit deeper.
Yeah, "production-ready" is definitely true about Caddy, but I know saying a program is "production-ready" is like saying a program is "secure" -- what does that even mean??
I like to tell people it's production-ready if it's a good fit for your website and workflow. Many people are using Caddy in production. There's so much variance it's hard to pin it down in a simple phrase, so we have to settle with a term that's "good enough", which I think the most fitting is "production-ready."
And upfront, I'll say: Careful with chasing benchmarks. They don't transfer well (or at all), and most people (including me) don't know how to run them properly. Just test with your own staging setups and see if it works well enough for what you need.
Anyway, thanks for your feedback about the site -- definitely taking it into account.
I think Caddy is doing a lot of things pretty great (including having a very large amount of cool features and a very simple configuration syntax).
However, honestly, I don't dare to use it on "big" production sites yet (besides maybe my blog), because for example packaging [0] still isn't tackled or clear at this point in time (and if Caddy wants to also gain traction on "big" production websites, this matters, because these are often not just run by devs, but sysops/devops people that will, very likely, never wget a binary because [insert one or more of valid reasons]). I think Matt (mholt) said that they will work this out when Caddy will hit 1.x, but for me it is a showstopper atm. Also if you read the topic from top to bottom you will notice that there seems to be no clear vision, not even for a base-caddy OS package or PPA.
Before this comment is considered negative, please know that I am actually a Contributor to the Caddy project (yet I have only contributed to the Init/Service Scripts), and a passive reader of the packaging discussion mentioned earlier, trying to come up with a great idea there to tackle that one point that I think will make Caddy's growth accelerate very quickly for "big" production websites.
I agree with you 100%, this is the primary reason why we haven't deployed caddy for at least internal services where I work. I don't want to have to upgrade "everything and caddy" every time the update window rolls up.
>The only thing I'm initially a tiny bit weary about is their claim of it being production ready. Being used by thousands of sites is an amazing feat, but how big are the loads on these sites?
Well, you can always add more boxes.
People have been putting horrendously performing Ruby or other small-time servers in production for very mainstream sites.Compared to things like these, Caddy will soar...
caddy doesn't scale or handle high traffic as well as nginx does from my benchmarks and understandably as caddy author has stated, he's focusing on features first then performance. benchmarks caddy vs nginx - caddy uses up to 3x times more cpu and memory resources and 1/3rd the performance of nginx https://community.centminmod.com/threads/caddy-http-2-server...
edit: This is also where your use case makes it easy to see why nginx (or caddy) won't cut it.