> although I will never be a fan of its JSON config file option
Well, if you use a Caddyfile, the JSON config is just an implementation detail. That decision shouldn't matter to you. The fact is, JSON is the best option for Caddy _at runtime_ to manage its config in memory, especially because Go has first-class support for unmarshaling JSON documents onto a tree of structs.
I love and use JSON every day. I just don't philosophically believe that it's the right thing for configuration. Too much scope for making errors if done by hand.
And also if not doing it by hand, it means additional tooling to create the JSON file. Another layer to deal with with so many layers already.
Also Go's first class support for JSON is not a reason for supporting JSON in configuration files. Pretty much every language supports JSON anyway, so whether it's "first class" or "second class" does not really matter.
Anyway, we love and use Caddy here. We just don't use the JSON config file.
That’s the main reason we no longer use it for our multi-tenant SaaS systems.
Caddy powers our thousands of domains - although I will never be a fan of its JSON config file option, it works very very well for us.
Otherwise… it’s great.