no, that's asking if an enterprise grade project is fronted with Caddy.
> People use it for "real" projects. (I do.)
Sure, but you're not Facebook, Google or Oracle, or big brand X or Z. If you can get Coca Cola, or Nike website run on Caddy, it will change that perception.
However most companies out there aren't Facebook, Google, Oracle, Coca Cola or Nike anyway.
Here's an example how a missing option (that is Go 1.8+ - which is a recent release) can lead to a DoS: https://github.com/containous/traefik/issues/1322
(Caddy, in my experience is production quality. I've used it in a few projects and haven't had any serious issues. Maybe that's just my use cases, though.)
Just because you'll be the first to use something for some purpose doesn't make the tool unfit for said purpose.
The parent post's point stands: "production-ready", like "secure", is a highly relative term.
While Caddy doesn't do that, production readiness is something that can be objectively measured. Define some metric, like "how many % users encounter stability-related issues/error conditions", throw in telemetry and there will be solid numbers. Many do that with their own software deployments, using Sentry or similar solutions, deciding on whenever their beta deployments are "production ready" or "not yet". Of course, that only works with a large enough user base, otherwise the error margins are too high for the number to be any meaningful. It is relative only in regard whenever, say, "0.01% (just a random number) of users have encountered severe issues" is "way too many" or "oh, it's just a few".
Security, on the other hand, is a different beast. Formal proofs aside - trying to define some similar metric "how many installations were hacked" or "how many security issues were found" isn't really meaningful.
But I think it would be really off-topic. =/
The point is that knowing about previous use in production is one way of knowing to what extent something is production-ready. There are other ways (e.g.: well-controlled tests).
As for your point about security, I couldn't disagree more strongly. Comparing histories of compromises and mitigations across various projects is, in practice, a very useful metric. See OpenBSD for an example.