I want to start by saying I am fully aware of all the caveats about running Caddy in production. But I like the principles and execution of Caddy and want to try on two low traffic sites.
That said, I am hosting about 5 domains (counting .host.com, www.host.com, etc).
If one of those domains fails, the whole server doesn’t start up, so all my sites go down. This seems to be a pretty serious design flaw.
Shouldn’t only the domain that failed, not be hosted? Why should all the other domains (including ones with valid certs) fail to host and the whole server crash?
This isn’t an issue of a config parse error, just a TLS verification error (because my new domain hasn’t propagated yet).
This is a common misunderstanding. When Caddy is starting, there are no sites to take down, because Caddy was not running before. If you stopped the server before, then you took the sites down yourself. On the other hand, if you use signal USR1 to reload an updated Caddyfile while Caddy is running, Caddy will not stop serving the old sites if a new one fails to come online.
Additionally, this is the same as other web servers like nginx. If it can’t resolve the domain you tell it to bind to, it can’t start. Definitely not a design flaw.
Once your DNS has been configured correctly, you can use Caddy (or other web servers) to serve your site.
Ah yes you’re right – I actually do systemctl restart caddy. I’ll start to do the USR1 to reload. (I’m used to doing service reload nginx and didn’t find a similar for the caddy systemd file… is there an easy way to do that using systemd?
I dunno actually; I don’t use systemd (nor am I familiar with it at all) – but there are some people here who use it all the time and can help you better. I’ll wait for someone else to answer.
This was my mistake – I just looked through the systemd file in examples and there is an ExecReload directive. So I AM able to say systemctl reload caddy – my apologies, needed to RTFM a bit. Leaving this answer here in case anyone else hits the same issue.