Sure, but it'll never reach maturity if you don't try it! We're always looking for more people to test things out, give their thoughts, and contribute ideas or fixes.
I think that is the problematic point with Caddy right now - if you are using it, you are actually a beta tester. This is a problem for sites with lots of traffic because things start to be different with servers maxed out - Nginx is battle hardened, learned it´s lessons and you can be sure that it works under extreme load as expected.
Also you definitely need rate limiting out of the box, not as some beta plugin that needs to be fiddled in manually.
Also streaming is something that needs really good testing with high loads.
K8s is important for many people, too.
Of course it is not easy to find someone willing to test on a high traffic site when there are well established alternatives since many years and no actual problem needs to be solved.
"Easy configuration" is not very important for admins of high traffic sites. Not easy to find what could be the selling point for Caddy, but it should deliver one or two special things more.
We may eventually do that, but we need evidence that it's actually useful for people, since it adds to the long-term maintenance burden if we bundle it.
I look through my server logs sometimes and often see connection and request throttling being activated, by those who are hitting the servers with their automated exploit tools. I see having some sort of throttling as essential as being able to set the max client body file size to prevent abuse.
Of course, I could run something else in front of the server, but it's simpler for my use cases not to. The auto-SSL and simplified configuration were very attractive things about Caddy, however.
If your CMS provides it, maybe you could run an exit poll for people who demo Caddy, then look elsewhere, as I'm just speaking from my own experience.
Understood, I'm not saying it's not generally useful, I'm specifically talking about this implementation; is the way it was built useful, does it actually solve user's rate limiting needs? We need people to try to the plugin so we can mould it to user's needs. Then later we can bundle it once we're sure it's designed properly and we're locked-in on the approach taken.
However I wonder if it would work better if the module were brought under the Caddy namespace and marked "beta".
At least then, there would be a show of commitment for the idea, if not the implementation.
Recently I've been looking at the Symfony framework, and this is how they introduce features, with a clear warning that the API etc. is subject to change.
Understood, but we don't want to ship something half-baked in the standard distribution. So we offer it as a plugin first so it can be worked on and polished without being tied to Caddy's versioning. Please try it out and give specific feedback on the plugin. We need to hear if there's any functionality missing or if the design doesn't fit user's needs before we can bundle it.
But I think Caddy is a fine server as well.