Shortcomings of the article aside, I'd like to say that I use Caddy for a set of small websites and I couldn't really be happier with it.<p>I'm a longtime Windows developer who doesn't have much patience with nerdy complexities. I started in 1996 with a buggy, gawd-awful Netscape webserver, moved to the late-lamented O'Reilly WebSite (even had a T-Shirt) and reluctantly settled on MS IIS, with occasional Apache encounters. Caddy has been an absolute breath of fresh air.<p>I currently run 4 sites from a system at my home, using Namecheap dynamic DNS. Caddy serves the basic web pages and static content and also reverse proxies to an internal Python server for dynamic content. Sounds a little complicated, but believe me, configuration is dead-simple thanks to Caddy. Plus I get full HTTPS from Let's Encrypt for the cost of supplying my email address and agreeing to a EULA - no configuration needed at all.<p>I've never used a webserver that was easier to configure or had such low resource requirements.
>The configuration is not that intuitive and you really need to get into the syntax and concepts to get an understanding of knobs to turn in order to achieve a certain goal.<p>Personally I found Nginx configuration much simpler than Apache. I think Nginx is pretty intuitive, it certainly is much supplier than IIS, which is a nightmare.
> every middleware you want to use needs to be included into the binary and if it’s not, you need to re-compile the program<p>Having to recompile to add functionality that alternatives provide as dynamically loaded plugins is insane. This is 2017. Linux has had loadable <i>kernel</i> modules since 1995, and I worked on them for other versions of UNIX as far back as 1991. I understand that it's hard for a Go program to support plugins written in other languages using a more conventional runtime. No problem there. However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime. I really want to like Go, but as long as the Go community clings to long-discredited ideas regarding things like packaging and distribution and symbol versioning I just don't feel like I can depend on it to build infrastructure that will remain robust over time.
I've been experimenting with Caddy over the past few days and it's great, if somewhat immature and quirky. The plugin ecosystem is rich but in dire need of some oversight and QC. What I like most about Caddy is its very sane behavior out of the box: it just does the right thing in most cases, and requires much less configuration than NGINX, Apache, HAProxy, etc. (It also has fewer features, so there's a trade-off.)<p>I posted a gist[0] with my Caddy+Varnish+PHP-FPM configuration and a README explaining the hows and whys. I'm moving a bunch of WordPress sites from Apache/mod_php to this configuration (each site's PHP-FPM instance is Dockerized, but that's out of the scope of the gist). Hopefully someone finds it helpful!<p>0. <a href="https://gist.github.com/mwpastore/f42f6f1309a7b067519f4c08e18b0b6a" rel="nofollow">https://gist.github.com/mwpastore/f42f6f1309a7b067519f4c08e1...</a>
I like caddy, but the dreamhost benchmark re apache vs nginx isn't really telling, as it doesn't mention fundamental apache config properties. I'm assuming they were benchmarking an unoptimized MPM/prefork setup, but you can use event-based request processing (and other process models) with apache as well. There's nothing magical with nginx.<p>I'd also like to see a benchmark vs. H2O which seems to have the most advanced HTTP/2 support right now (its running the nghttp2 web site for some time now).
Some of your links to <a href="https://caddyserver.com/" rel="nofollow">https://caddyserver.com/</a> are relative and not absolute, leading me to <a href="https://ferdinand-muetsch.de/caddyserver.com" rel="nofollow">https://ferdinand-muetsch.de/caddyserver.com</a> - Something you should consider fixing.<p>All in all however, I like the look of Caddy. The best bit I feel has been left out though:<p>"That is why, effective this release, Caddy will automatically serve all live sites over HTTPS without user intervention."<p>Which I think is just brilliant.
> You don’t need to run any script. You don’t even need to create a Let’s Encrypt account or install the certbot.<p>How is this done? Ie, to not need any account and still get new/valid certs.<p>And, on that note, what is the difference between having an account and not? Eg, how might using no accounts harm a production environment?<p>Just trying to wrap my head around that. Really cool UX for side stuff!<p><i></i>edit<i></i>: Ah, looks like there is an account involved - it creates one, possibly using your email address. This makes more sense now.
I like caddy and I use in inside of docker for my private home/cloud setup but lately I've been rethinking even that. I agree it's almost magical in how easy it is to setup (especially with HTTPS) but I use nginx for serious projects and a large part of me says it's better to use the same thing everywhere to keep me up to date and aware of potential issues or features and not mix the two.
The graph is marked as 'Apache2 vs. nginx memory usage ' but that's not what it shows at all - it's 'Requests per second on Apachev2 vs nginx' - did you mean to show <a href="https://objects-us-west-1.dream.io/kbimages/images/Webserver_memory_graph.jpg" rel="nofollow">https://objects-us-west-1.dream.io/kbimages/images/Webserver...</a> instead?