Welcome Travis! Thanks for sharing your use case. Always helpful to know that.
The same concerns as with any other web server apply with the addition of the ACME challenges: if Caddy is to solve them, it needs the external ports 80 and 443 forwarded to it. So if Caddy is behind a CDN or any kind of proxy or connection terminator, you will need to make sure that ACME challenge HTTP requests and ACME challenge TLS connections go directly to Caddy; do not pass go, do not terminate TLS. Most CDNs should have a way to enable that.
There’s a WIP cache plugin: GitHub - caddyserver/cache-handler: Distributed HTTP caching module for Caddy - however, unless the community comes together to finish building it (I can supervise), best bet is for a company to hire Ardan Labs to develop it: https://caddyserver.com/business (they work in close contact with me for Caddy dev).
Well, Google, Netflix, and Cloudflare all use Go in production. I don’t have any hard numbers for you though. You’ll have to experiment and let us know. If you encounter any issues, do a profile and let’s optimize it. Unfortunately most people are too anxious to run useless benchmarks that test too many stacks and we can’t improve anything from that, since they don’t reveal any useful information. We need actual memory and CPU profiles for very specific loads.
Thanks, we don’t hear a lot of good things about our docs, but we work hard on them.
Just set the default log’s level to DEBUG. There’s not a lot of debug logs yet but we do emit URI rewrites and reverse proxy requests in the debug logs, which helps a majority of cases. We can add more if we find places where it would be useful. My recommendation with logging is to just let Caddy log anything and everything out to a single place and then you can aggregate and process them with proper tooling.