I use caddy and I'm quite happy with it over apache and nginx, but I'd happily give my opinion if this helps OP to make this something different and hopefully even better than caddy.
I love auto TLS and caddyfiles are easy to understand. Modularity is important and templates can be very useful. Serving files and using caddy as reverse proxy are the most common uses I make of it in production, but I also use caddy in dev and it's a boon. Ease of config means my team can easily pick up my work and continue from there, even if they are not as proficient with the tool.
I don't love caddyfile directive ordering: sometimes my colleagues are confused because directives have an implicit order that is not obvious: instead of reordering directives, I'd rather have a warning/error message saying "this config doesn't make sense because you cannot do this and that", or just follow the order used in the config file + warnings.
I use it a lot to prototype and mock APIs during development, e.g. to have endpoints returning html pages or json documents: static files and templates are useful for this and I wouldn't consider something without this feature, though go templates aren't that great and/or caddy docs are a bit lacking (e.g. a simple loop over 0,1,2,3... Is not obvious!)
I don't find caddy great (or I don't know how to use it) to debug things when they are not working as expected. I often find myself replacing parts of the infra with netcat so that I can inspect what is going on. It would be great to have a "debug endpoint", like a webpage I could connect to and inspect all the traffic like MITM proxy, it would be awesome. Being able to inject myself in a route and manually change headers, responses, requests etc, it would be fantastic and a great help in debugging issues. Also, being able to start this "inspection mode" while in production would be nice, without having to restart the server (something is off -> I ssh-port-forward to the server host -> connect my browser to the server and inspect the errors -> find the issue and fix the config).
Management of certs could be improved in some edge cases. For example, I'd be happy if it was easier to manage certs in a private subnet. For example, say host A could acquire certs for my domain example.com with DNS challenge, then a host B, not public facing but in a subnet with A, could ask A to manage its certificates and still have valid https (letsencrypt provided certs) inside the network.
One thing I also don’t like in caddy is the lack of caching configuration available without using a partially implemented extension. I find it quite important as a reverse proxy with nginx.
I agree with the implicit ordering of marchers in caddy.
Also, while I love Rust and I'm a big fan of the language, please stop saying "it's made with Rust!". Really, it's only annoying and irrelevant to the quality of a project and it might even be counterproductive. Who cares what language is used for a software as long as it works great ;)
This holds in general, not only for this project in particular.
I love auto TLS and caddyfiles are easy to understand. Modularity is important and templates can be very useful. Serving files and using caddy as reverse proxy are the most common uses I make of it in production, but I also use caddy in dev and it's a boon. Ease of config means my team can easily pick up my work and continue from there, even if they are not as proficient with the tool.
I don't love caddyfile directive ordering: sometimes my colleagues are confused because directives have an implicit order that is not obvious: instead of reordering directives, I'd rather have a warning/error message saying "this config doesn't make sense because you cannot do this and that", or just follow the order used in the config file + warnings.
I use it a lot to prototype and mock APIs during development, e.g. to have endpoints returning html pages or json documents: static files and templates are useful for this and I wouldn't consider something without this feature, though go templates aren't that great and/or caddy docs are a bit lacking (e.g. a simple loop over 0,1,2,3... Is not obvious!)
I don't find caddy great (or I don't know how to use it) to debug things when they are not working as expected. I often find myself replacing parts of the infra with netcat so that I can inspect what is going on. It would be great to have a "debug endpoint", like a webpage I could connect to and inspect all the traffic like MITM proxy, it would be awesome. Being able to inject myself in a route and manually change headers, responses, requests etc, it would be fantastic and a great help in debugging issues. Also, being able to start this "inspection mode" while in production would be nice, without having to restart the server (something is off -> I ssh-port-forward to the server host -> connect my browser to the server and inspect the errors -> find the issue and fix the config).
Management of certs could be improved in some edge cases. For example, I'd be happy if it was easier to manage certs in a private subnet. For example, say host A could acquire certs for my domain example.com with DNS challenge, then a host B, not public facing but in a subnet with A, could ask A to manage its certificates and still have valid https (letsencrypt provided certs) inside the network.