What does it do that certbot doesn't? Personally, I don't see the benefit of bundling certificate renewals with the HTTPS server.
Caddy is written in Go, a memory safe language. I cannot overstate how significant it is that most servers like ngixn, Apache, and HAProxy are written in C and cannot offer the same security guarantees.
Caddy will also staple OCSP, in the most robust way compared to other servers. It has weathered outages that took Apache and NGINX sites down (in Firefox).
We've also seen CertBot consume high amounts of resources at scale, whereas Caddy can handle thousands of certs no problem. That's why some companies have talked to me about why they switched.
Caddy can coordinate cert management in a cluster. This happens automatically when configured with the same storage backend. CertBot doesn't do that. Caddy works great behind reverse proxies, or as the reverse proxy.
Perhaps most importantly, Caddy is the only server to use HTTPS by default without needing any explicit configuration. You simplify your deployment workflows and have less room for things to go wrong.
There's also a values statement here... If you think privacy and security are important, you choose software that enables privacy by default because it aligns with your values.
Sure, any number of solutions can get you TLS and a few even get you TLS via ACME, but Caddy (2) is highly optimized to handle the edge cases and scaling requirements a lot of sites have these days.
You don't have to run Caddy as root in production, even to bind to low ports. (None of my sites do.) https://memorysafety.fail for more info on memory unsafety.
You had said:
> Go's memory safety isn't some kind of automatic security guarantee...
But in some cases, it is. I'm not claiming more than that, nor am I saying that you can't have "bugs of other kinds" -- on which point I agree with you.
Fair enough, it's easy to misunderstand the intended tone in online comments.
Asking because I run Go based servers (in production) on Linux, and they're not running any of the Go processes as root.
It seems like they've fixed their systemd config though to run as a non-privileged user, so that shouldn't be an issue. But it seems like Go processes can't drop privileges because of an open issue with the runtime.