Caddy's strange official binary licencing did them no favours. The licensing makes more sense now but they are off people's radar.

This might change with Caddy 2.0.

It changed months ago. It's all Apache licensed.

I think they meant that it'll be back on people's radars once there is a big release.

One thing that drives me off from Caddy is that many features don't compose with each other well. I understand this might be a sacrifice for a simpler user interface, but the composition of declarative-style configurations is always a mess compared to imperative ones like nginx.conf

Thanks for the feedback.

(To clarify, nginx's config is also declarative... well, mostly: they got in trouble for mixing declarative and imperative [1].)

You'd be surprised what we've been able to accomplish with upgrades to Caddy's configuration in Caddy 2. Its config is technically declarative, but the underlying JSON structure [2] implies a procedural flow, enabling you to compose certain behaviors that almost feels imperative. When Caddy 2 release candidates go out in a couple months, try it out with both the Caddyfile (soon to be majorly improved in beta 13) and the underlying JSON and you'll see what I mean.

Oh, but if you want to still use your nginx config, go ahead (WIP) [3]. :)

[1]: https://www.nginx.com/resources/wiki/start/topics/depth/ifis...

[2]: https://caddyserver.com/docs/json/

[3]: https://github.com/caddyserver/nginx-adapter

Thank you for the quick reply! Currently our routing needs lots of flexibility, and we are wondering if it's possible to have something similar to OpenResty-style [0] config where builtin directives are Lua functions, and users can handle requests by dispatching them in Lua with a function call.

[0]: https://openresty.org/en/

We have a handler-scripting solution in the works that may be about 2x faster than nginx+Lua (from initial early benchmarks). Can you file an issue to request specifically what you need? https://github.com/caddyserver/caddy/issues/new