One site fails on startup - Caddy does not start

On a separate note, if it helps understanding, the decision to have Caddy bail out on a bad config is intentional. The reasoning behind it is that if there’s a problem, it’s important for the admin setting it up to deal with it straight away.

It’s also important to note that there’s a big difference between a service restart and container recycling. When you restart a Docker container, you’re not restarting the service, you’re shutting down the service and starting it again. Caddy can’t offer any graceful handling for configuration changes during this process without abandoning the principle of bailing out on a misconfiguration at startup, since you’ve killed its process and it can’t exactly persist the previous configuration.


If your heart is set on using container recycling to update configuration, you could consider a different architecture, one that’s more resilient to these kinds of configuration failures.

Since the main problem in your case seems to be TLS misconfiguration, you could do something like this, I wrote about some time ago:

A host-permissive, On-Demand TLS setup at the edge has minimal points of failure and starts up regardless of certificate-on-disk or network status - the point of failure for TLS issues would be delayed to client connection time. The configuration would be unlikely to change in the long run, too.

Instead of proxying back to HAProxy, send traffic back to your main Caddy instance - the one with all your individual site configuration - and use HTTP or self-signed over an internal network between the two. You can then muck around with your configuration all you like (assuming the Caddyfile syntax is correct…), and recycle both containers at will without fear of being unable to bring them back up properly due to TLS misconfiguration.

1 Like