The friendly licensing (Apache v2) is important too, especially w/ Caddy's modular architecture (single, static binary compiled for any platform).
Meaning ecosystems around Caddy to make it even simpler and more secure, e.g. keep your server private while serving Internet clients. So VPNs like Tailscale (1) or zero implicit trust like OpenZiti (also Apache v2; (2)). Similar to what we have seen with open source k8s ecosystem for example.
(1) https://tailscale.com/blog/caddy (and other VPNs but the proprietary bits in the commercial TS service make it easier to use)
Build-time modularity is a great balance between flexibility, installation simplicity, startup reliability, and binary size.
Look at all these comments put off at the idea that maybe the tiny annoyance of building the software to have the exact features you want is worth it for reducing deployment complexity. It's kinda sad actually, compiling software should not be so scary.
It's not tiny when you include the need for ongoing support. It's the difference between enabling unattended-upgrades and (mostly) forgetting the thing exists, or adding another item onto your CVE tracking list and either building pipelines to automatically rebuild and update the server, or doing it manually every time a security bulletin comes out.
When you have more than one system, it can't be just dismissed away.
Meaning ecosystems around Caddy to make it even simpler and more secure, e.g. keep your server private while serving Internet clients. So VPNs like Tailscale (1) or zero implicit trust like OpenZiti (also Apache v2; (2)). Similar to what we have seen with open source k8s ecosystem for example.
(1) https://tailscale.com/blog/caddy (and other VPNs but the proprietary bits in the commercial TS service make it easier to use)
(2) https://github.com/openziti-test-kitchen/ziti-caddy (disclosure: maintainer...there may be other open source zero implicit trust options with these types of Caddy integrations)