The thing I love most about caddy is it automatically does all the ssl certificate garbage which is so painful in every other web server ever. Yes certbot makes it less painful but it’s still a big PITA, unlike caddy where SSL is just like magic.

And zero dependencies!

This might solve my problem with older servers that no longer support the latest SSL.

I really need to upgrade those rickety old machines.

I suppose you mean zero runtime dependencies? It seems to have few dozen build dependencies.

Runtime dependencies create a nuisance as you have to update several things together. On the other hand, they can allow components with separate update cycles and responsibilities to be update separately.

Build dependencies create maintainability and security problems. They can also solve maintainability and security problems. It depends on what your consideration is. But as a matter of practice, many developers seem too concerned with possible behavioral/API breakage, that they like to pin to specific versions of their dependencies, which now means that you aren't getting any security fixes.

(Technically, Althttpd doesn't achieve zero runtime dependencies in comparison to a modern http server that does HTTPS, because it requires a separate program to terminate TLS. But these connect through general mechanisms that are much easier to combine and update separately.)

Everyone has to make a judgement about how they maintain their own systems, but being excited about "zero (runtime) dependencies!" isn't the way the judgement concludes.

You mean zero runtime deps because it pulls a lot of stuff when it does get built. Still great but I'd use traefik for more than 10 sites.

Caddy can serve thousands of sites without a sweat. What are your concerns exactly?

The webui based config helps for lots of sites and my clients can do it themselves without bothering me.

The only thing I don't really know how to do with it is round robin DNS for many servers with LetsEncrypt HTTPS.

It feels like then I'd probably need either shared storage for the certificate files (which goes against the idea of decentralization somewhat) or to use a DNS challenge type.

Anyone have experience with something like that?

Shared storage is the solution. Caddy supports multiple different storage backends (filesystem by default, and Redis, Consul, DynamoDB via plugins) and uses the storage to write locks so that one instance of Caddy can initiate the ACME order, and another can solve the challenge. See the docs: https://caddyserver.com/docs/automatic-https#storage

I'm doing this exact thing, with the Redis plugin behind DNSRR and it works seamlessly.

I fiddled around for many hours with traefik, and could not get it to do what I wanted -- something I'd done before and had a known example working config of.

10 minutes of caddy, I had everything running exactly as I wanted and the job was done.

I tried Traefik for the first time around 6 months ago (version 2) - man, coming from nginx (which I wouldn't call simple), I found Traefik config to be really confusing. It felt like I had to specify the same stuff 2 or 3 times, and in general it was just so unintuitive. And the docs (at the time at least) only showed snippets of trivial examples.

I don't think I'd choose to use it again. Instead, I'll try Caddy, or HAProxy if I need massive performance.

A big missing feature in Caddy for me is an embedded language like Lua for nginx so you can write tiny hooks. The Caddy authors have indicated on HN a while ago that Caddy 2 may have an embedded scripting language but I can't find anything about it in their docs.

Seems like it was postponed[0].

For very tiny hooks, you might be able to get away with using request matchers[1] and respond[2].

[0]: https://caddy.community/t/missing-starlark-documentation/958...

[1]: https://caddyserver.com/docs/caddyfile/matchers

[2]: https://caddyserver.com/docs/caddyfile/directives/respond

Writing plugins for Caddy is so easy that it's generally not necessary to have scripting built-in. You can just build yourself a new binary with a Go plugin just by using the "xcaddy" build tool. https://caddyserver.com/docs/extending-caddy

But yeah, it's still something at the back of our minds, and we were considering Starlark for this, but that hasn't really materialized because it's usually easier to just go with the plugin route.