How to Deploy a Cloudflare Worker for WordPress Media

You’ve offloaded your WordPress images to Cloudflare R2, but every image request still round-trips through your origin server. Your server fetches the file from R2, then sends it back to the visitor. That’s extra latency and unnecessary load on your host. A Cloudflare Worker can serve images directly from R2 at the edge — the nearest Cloudflare data center handles the request without your server ever being involved.

StaticQ Media includes a built-in wizard that deploys the Worker for you. No command line, no Wrangler CLI, no writing JavaScript. You enter your Cloudflare API credentials, click Deploy, and the wizard generates the Worker script, deploys it, sets up routes, and runs a verification test — all from your WordPress admin.

Prefer to watch? The video above walks through every step below.

---

What a Cloudflare Worker Does for Your Media

Without a Worker, the request path for an offloaded image looks like this:

Visitor → Cloudflare edge → Your origin server → R2 bucket → back through the chain

Your server is acting as a middleman. It receives the request, fetches the image from R2, and proxies it back. Every image load costs you server CPU, memory, and bandwidth.

With a Worker deployed, the path shortens:

Visitor → Cloudflare edge → R2 bucket → directly back to visitor

The Worker runs on Cloudflare’s edge network — the same data center that handles your visitor’s DNS request. It reads the image directly from your R2 bucket and serves it without ever contacting your origin server. The result is lower latency (images served from the nearest edge location), less server load (your WordPress host doesn’t handle image traffic), and better scalability (Cloudflare’s network handles the throughput).

The Worker also includes an origin fallback: if an image hasn’t been offloaded to R2 yet — maybe it’s still in the processing queue — the Worker falls back to your origin server and serves it from there. Nothing breaks while your library is being processed.

Prerequisites

Before deploying the Worker, you’ll need:

• StaticQ Media installed and activated on your WordPress site
• R2 configured and connected — your bucket is set up and the connection test passes (see the R2 setup guide if you haven’t done this)
• Your domain proxied through Cloudflare — the orange cloud icon should be enabled for your domain in Cloudflare DNS settings
• A Cloudflare API token with Worker permissions (we’ll create this below)

Step 1: Create a Cloudflare API Token

Log into your Cloudflare dashboard. Click your profile icon in the top right and go to My Profile > API Tokens.

Click Create Token. You can start from the “Edit Cloudflare Workers” template, or create a custom token with these permissions:

• Account / Workers Scripts — Edit
• Zone / Workers Routes — Edit

Scope it to your specific account and zone (domain) for security. Give it a descriptive name like “StaticQ Worker Deploy”.

Click Continue to Summary, then Create Token. Copy the token — you’ll need it in the next step.

Step 2: Enter Credentials in StaticQ Settings

Go to StaticQ > Settings in your WordPress admin. Scroll down to the Cloudflare Worker section.

Enter:

• Cloudflare API Token — the token you just created
• Zone ID — found on the Overview page of your domain in the Cloudflare dashboard (right sidebar)

StaticQ already knows your Account ID and R2 bucket details from your storage configuration. The Worker wizard uses these to generate a Worker script tailored to your setup.

Step 3: Deploy the Worker

Click Deploy Worker. The wizard handles everything:

1. Generates the Worker script — a JavaScript file that intercepts image requests on your domain, reads the corresponding object from your R2 bucket, and serves it with proper cache headers
2. Uploads the script to Cloudflare’s Workers platform via the API
3. Creates a route that maps your media URL pattern (e.g., yourdomain.com/wp-content/uploads/*) to the Worker
4. Binds your R2 bucket to the Worker so it can read objects directly

You’ll see a progress indicator as each step completes. The whole process takes about 10 seconds.

Step 4: Verify the Worker

After deployment completes, the wizard automatically runs a verification test. It requests a known image through the Worker route and confirms the response comes from R2, not your origin server.

You’ll see a green checkmark if everything is working. If the test fails, StaticQ tells you what went wrong — usually a permissions issue on the API token or a DNS configuration that needs the orange cloud enabled.

You can also verify manually: open a page on your site, inspect an image in DevTools, and check the response headers. You should see a cf-worker header indicating the response was served by your Worker.

How the Origin Fallback Works

The Worker doesn’t blindly assume every image is in R2. When a request comes in, it checks R2 first. If the object exists, it serves it directly from the edge. If the object doesn’t exist — because the image hasn’t been processed yet, or it was uploaded before StaticQ was installed — the Worker falls back to your origin server and fetches the image the traditional way.

This means you can deploy the Worker before your entire library has been offloaded. New visitors get edge-served images for everything that’s in R2, and origin-served images for everything that isn’t. As the processing queue works through your backlog, more and more requests shift to the edge path automatically. There’s no cutover moment and nothing breaks during the transition.

Performance Benefits

The difference is most noticeable on image-heavy pages. Without the Worker, every image request hits your origin server — even if the file is in R2, your server still acts as a proxy. With the Worker:

• Lower latency: images are served from the Cloudflare edge location nearest to the visitor, which could be in a different continent than your origin server
• Reduced server load: your WordPress host handles zero image traffic for offloaded files, freeing CPU and bandwidth for actual page requests
• Better cache hit rates: Cloudflare’s edge cache works more efficiently when the Worker serves directly from R2, since there’s no origin round-trip to add variance
• Consistent performance under traffic spikes: a viral post with 50 images per page doesn’t hammer your server — Cloudflare’s network absorbs the load

For sites on shared hosting, this is especially significant. Your hosting account’s resource limits apply to origin requests. Worker-served image traffic doesn’t count against those limits.

Managing the Worker

Once deployed, you can manage the Worker directly from StaticQ’s settings page:

• Test: re-run the verification test anytime to confirm the Worker is functioning
• Redeploy: if you change R2 buckets or update settings, redeploy to push a fresh Worker script with the new configuration
• Undeploy: remove the Worker and its routes entirely, reverting to origin-served images

You don’t need to log into the Cloudflare dashboard or use the Wrangler CLI for any of this. StaticQ handles the API calls.

What You’ve Built

In about five minutes, you’ve moved your image delivery from origin-proxied to edge-served:

• Images served from the nearest Cloudflare edge — no round-trip to your origin server
• Origin fallback for images not yet in R2 — nothing breaks during the transition
• Zero server load for offloaded images — your host handles pages, Cloudflare handles media
• One-click management — deploy, test, redeploy, or undeploy from your WordPress admin
• Total cost: $0 — Cloudflare Workers free tier includes 100,000 requests per day, and R2 reads are free

Combined with R2 offloading and WebP delivery, this completes the pipeline: images are processed on upload, stored in R2, converted to WebP, and served directly from the edge with automatic fallback. Your origin server’s only job is serving HTML.

Get StaticQ Media →