I mean, technically yes, since the only the Caddy's `main()` does is call a function that parses CLI args; all of Caddy's logic is in importable packages. But in order to be useful you'd have to have a config document (usually JSON, or some other supported format through Config Adapters) to pass into either `Load()` or `Run()`: https://pkg.go.dev/github.com/caddyserver/caddy/v2?tab=doc#L...
Nothing wrong with having to pass in a config, though it’s a question of control for me, like being able to use the full power of Go to handle complex scenarios, hot loading modules etc.
Have you given this any serious consideration making it more API friendly for developers in this way?
My issue with modules is you will inherently be limited at a certain point
If you need that much or absolute control, I'd recommend don't use a framework or high-level library at all.
As for specific features or functionality, feel free to ask on our forums in more detail, or request it on the issue tracker. I don't really know what "complex scenarios" entails here, or "hot loading modules" can mean a lot of things.
But most people do it the other way around: write a Go program or library and then make it a Caddy module: https://caddyserver.com/docs/extending-caddy