Purge Cloudflare edge cache on deploy (then raise s-maxage)

[marekh19]

Problem

Cache headers in public/_headers use s-maxage to edge-cache HTML on Cloudflare. Confirmed live with cf-cache-status: HIT.

A redeploy does NOT purge Cloudflare's edge cache for a URL whose path is unchanged (per Cloudflare docs: updating a static asset under the same filename keeps serving the old cached copy until the edge TTL expires). HTML pages keep the same URL across deploys, so s-maxage is the real staleness ceiling — max-age=0 on the browser doesn't help, since a revalidating browser still hits a "fresh" (stale-content) edge entry.

Effect today: after publishing or fixing a post, the edit can take up to s-maxage to appear (currently 1h lists / 3h detail pages). Bounded, but not instant.

Proposed fix — purge on deploy

Purge the edge cache after wrangler deploy, then crank TTLs long (lists can go long too, since a new post becomes visible the moment the cache is purged).

Steps

1. Token — current Cloudflare API token has no cache-purge scope (only Workers + Workers Routes:Edit on the zone). Add Zone · Cache Purge · Purge for the domain zone.
2. Secret — add a CLOUDFLARE_ZONE_ID repo secret (the Zone ID, not the Account ID).
3. Workflows — add a purge step after deploy in both deploy-production.yml and deploy-staging.yml. Use curl -f so a failed purge (e.g. missing permission) fails the deploy loudly instead of silently leaving stale content:

   curl -fsS -X POST \
     "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
     -H "Authorization: Bearer $CF_API_TOKEN" \
     -H "Content-Type: application/json" \
     --data '{"purge_everything":true}'
   

4. Bump TTLs — once purge is verified, raise s-maxage on list + detail pages (e.g. 30 days). Deploy = instantly live.

Notes

• For ~monthly publishing the performance gain is marginal (assets already on CF's network, near-100% hit rate between deploys). The real win is correctness: edits go live immediately on deploy instead of waiting up to the TTL.
• Low priority — revisit when a stale fix becomes annoying.