caddy reload: Apply Caddy Config Changes
caddy reload validates a new config and loads it into the running server through the admin API with no downtime.
reload is the deploy-safe way to apply Caddy changes. It sends the new config to the admin endpoint; if the config is invalid, the running server keeps serving the old one.
What it does
caddy reload adapts and validates the new config, then POSTs it to the running instance admin API (default http://localhost:2019). The server loads it gracefully. If the new config is invalid, the reload fails and the old config stays active, so a bad deploy does not drop traffic.
Common usage
caddy reload --config Caddyfile
# target an admin API on a non-default address
caddy reload --config Caddyfile --address localhost:2019
# validate first for a clean failing exit in CI
caddy validate --config Caddyfile && caddy reload --config CaddyfileOptions
| Flag | What it does |
|---|---|
| --config <file> | New config file to load |
| --adapter <name> | Config adapter to use |
| --address <addr> | Admin API address of the running instance |
| --force | Reload even if the config is unchanged |
In CI
reload beats restarting the process: it is atomic and keeps connections alive. Pair caddy validate with caddy reload so the pipeline fails loudly on a bad config rather than relying on the silent old-config fallback. If you disabled the admin API, reload cannot work; use caddy run --watch or a restart instead.
Common errors in CI
reload: sending configuration to instance: ... connection refused means no server is running or the admin API is off or on a different --address. "loading new config: ..." means the new config failed to adapt or provision. "admin endpoint disabled" means the running config set admin off, so reload has no endpoint to call.