There are some features in Caddy that are simply outstanding - HTTP/2 and Let's Encrypt integration, to name a few - both pretty much work out-of-the-box with zero-configuration.<p>On the other hand, there are still some gaping holes - for example, to block (or allow) a 192.168.0.0/17 IPv4 subnet in Caddy, one needs to do all of below:<p>- Install an addon [1];<p>- Which used to require recompilation, with 0.9 release you can just click an option during download, yay!;<p>- Add 128 ranges to cover this single subnet: 192.168.0.0-255, 192.168.1.0-255, ...192.168.127.0-255. Configuration doesn't support subnets, only ranges. And only ranges in last octet, i.e. 192.168.1.0-255 (meaning 192.168.1.0/24), or implied ranges by trailing octet(s) omission, i.e. 192.168 (meaning 192.168.0.0/16) [2].<p>Oh, and ipv6 filtering doesn't exist at all.<p>[1] <a href="https://caddyserver.com/docs/ipfilter" rel="nofollow">https://caddyserver.com/docs/ipfilter</a><p>[2] Which is mildly confusing notation too, since traditional UNIX inet_aton() call would interpret this as 192.0.0.168. Try typing "ping 192.168" on Linux.
Shameless plug: if you're interested in knowing more about the Caddy webserver, I did an interview with Matt Holt - its creator - a few weeks ago on the SysCast podcast: <a href="http://podcast.sysca.st/podcast/1-matt-holt-creator-caddy-webserver/" rel="nofollow">http://podcast.sysca.st/podcast/1-matt-holt-creator-caddy-we...</a>
I would love to hear experiences from people/companies using Caddy in production (for example, replacing nginx). The project looks very promising, but for production usage one might also like a decent group of other people using it in production.
The one thing that bothers me (which is not Caddy's fault at all) is the plugin system. If I understand correctly, I have to recompile Caddy for every plugin I want to use, right? Sounds like a limitation with Go which is really unfortunate.
I'm awesome to see Caddy come so far. We started using Caddy a little over a year ago, when we needed a replacement for nginx as a reverse proxy that could talk directly to mesos to figure out routing. At the time I rewrote the reverse proxy middleware to get the functionality I needed, but we ended up maintaining our own fork (which is now widely behind), because we needed our own plugins (and a mesos reverse proxy didn't seem useful enough to integrate into caddy core), so its great to see first class support for plugins.
Can Caddy work as a reverse proxy to other backend services? And if so, can I use QUIC for the backend and plain TCP for the front-end? Would that give me any benefit?
API Bootstrapping<p>What if you could slap something like Caddy in front of any API and provide authentication, analytics even billing out of the box.<p><pre><code> - Rate limiting
- Billing
- Authentication and Authorization using OAuth or JWT
- Analytics/Metrics
- Geo Location
- TLS
- HTTP2?
- Image optimization
- Content minification
- Gzip
- Signaling Slack/Push/SMS
- Caching through cloud storage S3, BlackBlaze B2
- PostgREST</code></pre>
When I went to use Caddy (because I love the idea of it), I was disappointed to find that there was no yum repo.<p>Of course, this makes sense because you have to compile the features in.<p>But, it would still be nice to have deployment automate-able. Maybe an Ansible role that combines the feature list you need and downloads it via an API.<p>It's the major, and only reason I quit and went back to nginx.
I just replaced nginx with caddy on a staging server. Works flawlessly, very easy to install. The docs could use some improvement though, especially in the way of examples.
Can I use Caddy to provide a single point of authentication for multiple apps when acting as a reverse proxy?<p>So a request to a protected resource needs to be authenticated if not then redirect to a URL (login form).<p>If login is successful then a token is provided which can be used for authentication.<p>If a request is authenticated successfully then it can proxy to the resource.