When a deployment finishes, your origin server has the new code — but your users still see the old CSS, the old JavaScript, the old images. Cloudflare's edge cache is faithfully serving the version it has, and it has no idea you deployed.
The fix is to tell Cloudflare to purge the cache as part of the deployment itself. DeployHQ ships a built-in Cloudflare integration that does exactly this — every push, every deploy, automatically. No webhooks to maintain, no curl scripts to babysit.
This guide walks through the setup, explains when to purge everything vs only changed files, and covers the caveats that turn into 2 AM support tickets.
Why cache invalidation matters for deployments
A CDN like Cloudflare caches your static assets at hundreds of edge locations. A user in Tokyo doesn't hit your origin in London — they get whatever the nearest edge has. That's great for performance. It's a problem the moment you deploy.
Three failure modes:
- Mixed-version pages. New HTML loads with old CSS or old JavaScript. Layouts break, hydration fails, your error tracker fills up with phantom bugs.
- Stale fixes. You pushed a critical patch. Users don't see it until the TTL expires — which on a default Cloudflare config can be hours.
- Cache poisoning windows. If the new HTML and old asset are cached together for a user, that broken combination sticks around until the cache expires.
Purging the cache on every deploy eliminates all three. With DeployHQ's automated deployments, it happens without you thinking about it.
Set up the Cloudflare integration in DeployHQ
Step 1 — Generate a scoped API Token in Cloudflare
This used to be done with your Cloudflare Email + Global API Key. Don't do that anymore. Global API Keys have full account access, and Cloudflare itself recommends API Tokens for any integration today.
- In Cloudflare, go to My Profile → API Tokens → Create Token.
- Use the Custom token template.
- Permissions: Zone → Cache Purge → Purge.
- Zone Resources: Include → Specific zone → [your domain].
- Save. Copy the token immediately — Cloudflare only shows it once.
You'll also need your Zone ID (found on the Cloudflare dashboard overview for that zone).
Step 2 — Add the notification in DeployHQ
In your DeployHQ project, click Notifications in the left sidebar, then New Notification.
Choose Cloudflare in the Service dropdown, then fill in:
- Zone ID — from the Cloudflare zone overview.
- Asset URL Prefix — the public URL prefix for assets you want purged (e.g.
https://www.example.org). DeployHQ uses this to build the file URLs it sends to Cloudflare's purge endpoint. - API Token — the scoped token you generated in Step 1.
Step 3 — Choose purge everything vs purge by file
- Purge Everything ON — Cloudflare drops the entire zone cache on every deploy. Simple. Heavy. Costs you a temporary spike in origin traffic until the cache rebuilds. Use this if your changed-files list is unpredictable, or if you do server-side rendering with shared dependencies.
- Purge Everything OFF — DeployHQ sends Cloudflare only the URLs for files changed in this deploy. Fast, cheap, surgical. Use this for most static-asset workflows.
A small but important detail: Cloudflare's purge_cache API accepts up to 30 files per request and is rate-limited to 1,000 URLs per minute for the per-file purge endpoint. DeployHQ batches purges to stay inside those limits, so large deploys still complete cleanly.
Step 4 — Pick when to send the notification
In most cases, leave Send notification when any server or group deployed checked — you want the purge to fire whenever any of your servers receive a new deploy. If you maintain a staging zone with its own Cloudflare account, set up a second notification scoped to that server only.
Click Create Notification and you're done.
What cache invalidation does NOT fix
This is where the support tickets come from. Purging Cloudflare does not purge:
- Browser caches. Users with long
Cache-Control: max-ageheaders cached locally will still see old assets until that TTL expires. Mitigate with fingerprinted filenames (main.abc123.css) so new deploys produce new URLs that bypass the local cache entirely. - Service Worker caches. If you ship a PWA, your Service Worker is making the cache decisions, not Cloudflare. You need a separate cache-busting strategy at the SW layer.
- Origin shield caches. If you use Cloudflare's Tiered Cache or Argo, there's an additional layer. The standard purge clears it, but verify in the Cloudflare dashboard if you're seeing stale assets.
- HTML cached by Page Rules with very long TTLs. Worth double-checking your Page Rules — an aggressive HTML cache rule will undo most of what an asset purge buys you.
For an explanation of how this all fits into a deployment workflow, the longer-form how CDN cache invalidation works post walks through the full mental model.
Beyond cache purging: the full deploy story
Cache purging is one step. A robust deployment pipeline also wants:
- Zero-downtime deployments — so a half-finished deploy never serves a partial app.
- Build pipelines — compile, bundle, and fingerprint assets before they hit your CDN.
- Incremental deployment — only push files that actually changed, which is also what powers DeployHQ's per-file Cloudflare purge.
- If you also serve assets from object storage, the Cloudflare R2 vs AWS S3 comparison covers cost and egress tradeoffs.
Ready to stop manually purging caches? Sign up for DeployHQ and add a Cloudflare notification to your first project in under two minutes — included on every plan.
Questions? Email support@deployhq.com or reach us on X / Twitter.