> except for the explicit cert

That "except" is doing a lot of lifting, in my opinion. Automatic Let's Encrypt is a big part of why I reach for Caddy. Install, run, done. No cert management headaches. It felt like magic the first time I used it, and now that I think of it, it still does.

Right, in the nginx example above, someone has setup a secondary tool to provide certs at the location referenced, and is also handling renewal of them.

Also, if I want to add another domain that should be accepted and reverse proxied to my application, in Caddy I just do this:

    example.com wp.example.com caddyfreakingrules.example.com {
      root * /var/www/wordpress
      php_fastcgi unix//run/php/php-version-fpm.sock
      file_server
    }

Suddenly not only does my Wordpress site respond on example.com, but also wp.example.com, and caddyfreakingrules.example.com, Caddy will fetch and automatically rotate certs for all three domains, and Caddy will auto-redirect from http to https on all three domains. (Does the ngnix example actually do that?)

Another thing, does nginx with the above configuration automatically load new certs if the ones that were there when the process spawned have since expired? Because not only does Caddy automatically renew the certs, it is handled transparently and there's zero downtime (provided nothing changes about the DNS pointers of course).

Caddy is freaking awesome!

Bonus, if this were your Caddyfile (the entire thing, this is all that's needed!):

    {
      admin off
      auto_https prefer_wildcard
      email [email protected]
      cert_issuer acme {
        dir https://acme-v02.api.letsencrypt.org/directory
        resolvers 1.1.1.1 1.0.0.1
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
      }
      ocsp_stapling off
    }

    example.com wp.example.com caddyfreakingrules.example.com {
      root * /var/www/wordpress
      php_fastcgi unix//run/php/php-version-fpm.sock
      file_server
    }

    # This is simply to trigger generation of the wildcard cert without
    # responding with the Wordpress application on all of the domains.
    *.example.com {
      respond "This is not the app you're looking for" 404
    }

Then you'll disable the unauthenticated JSON API on localhost:2019 (which is a good security practice, this is my only gripe with Caddy, this API shouldn't be enabled by default), tell Caddy how to use the DNS-01 ACME resolver against Cloudflare (requires a plugin to Caddy, there are loads for many DNS providers), and then tell Caddy to use appropriate wildcard certs if it has generated them (which for *.example.com it will have).

The result of which is that Caddy will only generate one cert for the above 3 sites, and Let's Encrypt won't leak the existance of the wp.example.com and caddyfreakingrules.example.com domains via certificate transparency.

I'm under the sensation that nginx most recent release now handles automatic certificates out of the box. That confirms your perception of course.

This also has an include directive, so there’s more we’re not seeing. And what’s the SSLLabs score for that setup’s TLS?

But it’s not only the config that makes Caddy nice. I think that’s a good example of the kind of care and consideration that goes into Caddy’s development, though.