Reload without downtime

Configuration changes shouldn’t drop requests. Caddy is built around graceful reloads: it loads the new configuration, starts serving with it, and lets in-flight requests finish on the old one. Zero downtime — if you follow a safe sequence.

Here’s the sequence I use, every time:

caddy fmt --overwrite Caddyfile
caddy validate --config Caddyfile
caddy reload --config Caddyfile
curl -f https://app.example.com/health

Format, validate, reload, verify. Each step earns its place.

caddy validate catches a broken configuration on the spot, before the running server ever sees it. If validation fails, you just fixed a production incident that never happened.

caddy reload sends the new configuration to the running Caddy through its admin API on localhost:2019. The server applies it gracefully: listeners stay open and existing connections finish. And if the new config fails to load, Caddy keeps running the old one and the command reports the error. A bad reload gets you an error message, not an outage.

The final curl -f is behavior verification. A valid config is not necessarily a correct config — you can validly route all traffic to the wrong upstream. Hit a health endpoint and confirm the site does what you meant. The -f flag makes curl exit non-zero on HTTP errors, so the same line works in a deploy script.

Keep the previous known-good Caddyfile until that check passes. Version control makes this free: roll back by checking out the old file and running the same four commands.

What you should not do is systemctl restart caddy for routine changes. A restart kills connections mid-flight. Reload exists precisely so you never have to. Save restarts for upgrading the Caddy binary itself.

And the classic mistake, one more time because it costs people real debugging hours: editing the Caddyfile changes nothing on its own. Caddy doesn’t watch files. If the behavior doesn’t match the file, first ask yourself — did I actually reload?