Hey Brian, thanks for your request.
This is a common misunderstanding. Caddy doesn’t take all the sites down just because one can’t be served. If you are initially starting Caddy, there is nothing to take down because it was not running before. If you are reloading Caddy (signal USR1), it rolls back on error and doesn’t take your existing sites down.
Caddy needs to get verification from a third party (a certificate authority) before it can serve your site. If it can’t do that, it won’t. A half-working zombie server is not a good alternative because you would not want your web server running only some of your config, for the same reason you would not want to execute a truncated shell script.
In a sense, this is the same as nginx. If you tell nginx to bind to a hostname that can’t be resolved, it can’t start. From nginx’s Pitfalls and Common Mistakes page:
You should never use a hostname in a listen directive. While this may work, it will come with a large number of issues. One such issue being that the hostname may not resolve at boot time or during a service restart. This can cause NGINX to be unable to bind to the desired TCP socket which will prevent NGINX from starting at all.
With Caddy, our philosophy is a little different. Because security is not considered optional, you should use your real site name in the Caddyfile so that Caddy can serve your site securely for you. But this requires third party verification. Caddy won’t take your site down, but it won’t start when it knows there is a security problem.