Worker Recipe: Cache purge proxy

The following service worker example works as a proxy to the Cloudflare API, allowing you to purge cache for any zone within your Cloudflare account by just sending a request to domain.com/__purge_cache?zone=[zone_id]

The benefits?

  • Easily purge cache upon deployment by calling the /__purge_cache endpoint through a webhook
  • No need to expose global API keys to third party (deployment) tools

Note:
You may want to add further limitations by purging cache by cache tags, limit the script to only work for certain zones, or implement some sort of authentication/request verification.

7 Likes

Thanks for sharing! This will be really useful :smiley:

Especially when caching everything!

1 Like

I just added this to a couple of sites I manage. Now when they update content, they can click on a bookmark to immediately purge the cache.

4 Likes

Hi @martin2,

Thank you for providing this, this is great! I’m pretty new to setting up and using Workers, but my initial question about this would just be does this have to be set up with the route *example.com/* or can it be any route? What route do you recommend it is used with to work best? Hopefully, it doesn’t need to be used with the *example.com/* route as we’re starting to utilize that route on some of our sites that call upon a Worker with a Cache Everything script.

Thank you.

I actually have this on my “primary” zone. And because it has my Global API Key and email address, it will work for any zone in my account. So, naturally, I keep it a secret. The bookmark I mentioned is something like
purge.example.com/__purge_cache?zone=[zone_id]

but with actual zone ID in my bookmark. So I might have a Bookmark folder called PURGE, and in it is Domain A, Domain B, Domain C, etc. Each with that URL, but with their own Zone ID.

You may notice I’m using a subdomain. I have a DNS “AAAA” record for ‘purge’ with an IPv6 address of :: (yes, just two colons for a placeholder). And it’s set to :orange: Proxied. Then a Worker route of purge.example.com/*

p.s. If you want to protect that ‘purge’ subdomain, you can use Access so only your home IP address(es) and/or authorized email address(es) can make requests to that URL.

1 Like

Thank you for explaining this all! This was very helpful and you pretty much answered all the questions I had about setting this up. It appears to be currently working for us with the tests I’ve already done for our different sites. :pray:

I also set up a protection for the subdomain using Access/Cloudflare for Teams. I checked out the Common configurations documentation, however, I’m not totally sure if I’ve done the correct setup for it with what you suggested of only allowing certain IP addresses and/or authorized email addresses. The way I set it up is that we have two policies/rules for the protection:

  1. Include: IP Ranges; Decision: Bypass
  2. Include: Emails; Decision: Allow

I wanted certain IP addresses to be able to access the purge cache links right away and, if someone wasn’t within those IP addresses, then they could still be able to access/use the purge cache links if their email was listed in the 2nd policy/rule. If their email was listed in the policy/rule, then they’d receive a one-time PIN (OTP) by email to use to authenticate, which lets them through. If it wasn’t listed, then they wouldn’t receive the email with the OTP and wouldn’t be able to access/use the purge cache links.

Does this Access protection setup look correct to you or would you recommend changing some part of it?