Automatic HTTPS Certificate Renewal with Caddy and ACME

Fri, 11 Sep 2026 05:05:00 +0800

Automatic HTTPS certificate renewal in Caddy is not a cron job. Caddy obtains a certificate, serves HTTPS, redirects HTTP, and renews in the background when the hostname, public DNS, ACME challenge path, and certificate storage all work. A running Caddy process does not prove the next ACME attempt will succeed.

After issuance, the certificate, private key, and ACME account state are written to the data directory. Background renewal uses the same challenge path.

Automatic HTTPS certificate renewal only starts when these conditions hold

Caddy’s Automatic HTTPS documentation(opens in a new tab) requires all of the following at once:

Docker Compose Blue-Green: Health Check, Switch, Drain

Fri, 11 Sep 2026 05:00:00 +0800

A Docker Compose blue-green deployment on one server starts the candidate, waits until the app is ready, validates and switches the Caddy upstream, proves the public hostname, drains old connections, then stops the old version. Do not delete the old container before the candidate is taking traffic.

That sequence can shrink the unavailable window. The host, disk, Docker daemon, and shared database are still single points of failure, so measure the window instead of calling the result zero downtime.

The gateway switch is the only public cutover. Candidate startup and warmup happen before that switch.

Docker Compose blue-green only works under these constraints

Run two app instances on one host only when the service meets all of these conditions:

Caddy on StackOnward

Automatic HTTPS Certificate Renewal with Caddy and ACME

Automatic HTTPS certificate renewal only starts when these conditions hold

Docker Compose Blue-Green: Health Check, Switch, Drain

Docker Compose blue-green only works under these constraints