deploy/README.md

@@ -150,7 +150,9 @@ Re-run `ansible/` after a host resize — it is idempotent.
 workflow manually (Gitea → Actions → prod-deploy → run from `master`, input
 `confirm=deploy`). It builds + pushes the images to the registry, ships the
 compose/config/certs/env over SSH, deploys the main host with `prod-deploy.sh` (rolling,
-health-gated, **auto-rollback to the previous tag**), then the bot host, then probes the
+health-gated, **auto-rollback to the previous tag**; caddy is force-recreated on its roll so
+a bind-mounted `Caddyfile` change applies — its image is pinned and admin is off, so neither a
+new tag nor a hot reload would pick it up), then the bot host, then probes the
 public site. After `master` is green this workflow is the **only** thing that touches
 prod — nothing auto-deploys there. It runs four visible jobs: **build → deploy-main →
 deploy-bot → verify** (the per-service rolling shows in the deploy-main log).

deploy/prod-deploy.sh

@@ -74,7 +74,13 @@ health_running() { # health_running <container>: running, not restarting, stable
 roll() { # roll <service> <health-cmd...>
   local svc="$1"; shift
   echo ">>> rolling $svc -> $TAG"
-  dc up -d --no-build --no-deps "$svc" || return 1
+  # caddy's image is pinned (caddy:2-alpine, no $TAG) and its Caddyfile is bind-mounted, so a
+  # config-only change leaves the compose definition unchanged: `up -d` treats the container as
+  # current and does not recreate it, and admin is off so there is no hot reload — the new
+  # Caddyfile would never load. Force a recreate for caddy so config changes always apply; every
+  # other service already recreates on its new $TAG image.
+  local recreate=(); [ "$svc" = caddy ] && recreate=(--force-recreate)
+  dc up -d --no-build --no-deps "${recreate[@]}" "$svc" || return 1
   "$@" || { echo "!!! $svc failed health check"; return 1; }
   echo "<<< $svc healthy"
 }