Cloudflare Pages to Workers: Do You Need to Move?

I moved a static site from Cloudflare Pages to Workers in five minutes. The configuration change was one line; most of my time went to waiting for the deployment. A purely static blog may still have no reason to move.

What It Costs

The static-asset requests themselves are free on both platforms, within their platform limits. That does not mean every deployment, build, or dynamic request is free.

Pages documents its build limits. Workers pricing separates static assets from billed Worker execution and build usage. Check those current limits against your build frequency and runtime routes; the five-minute migration below records my October 2025 move.

I had been on the free tier for years. That was my bill, not a guarantee for every static blog.

One Line to Migrate

Pages already runs on Workers infrastructure. Change one property in your config:

- pages_build_output_dir: "./dist"
+ assets:
+   directory: "./dist"

Then redeploy the site.

Full steps:

1. Install Wrangler: bun install -D wrangler@latest
2. Update your config (see above)
3. Configure API token permissions (see below)
4. Deploy: bunx wrangler deploy

The official migration guide covers complex setups with Functions. Most static sites will not need it.

API Token Permissions

If you deploy with an API token (recommended for CI/CD), you need these permissions:

Match permissions to the deployment:

• Account -> Cloudflare Pages -> Edit (for Pages deployments)
• Account -> Workers Scripts -> Edit (for Workers deployments)
• Account -> Account Settings -> Read (for account info)

If you attach zone routes:

• Zone -> Workers Routes -> Edit (if using custom domains with your zone)

Setting up the token:

1. Go to Cloudflare Dashboard -> API Tokens
2. Click “Create Token”
3. Add only the permissions needed by your deployment target, scoped to its account and zone
4. For Zone permissions, select “Specific zone” and choose your domain (e.g., kahwee.com)
5. Save the token and set it as your CLOUDFLARE_API_TOKEN environment variable

What Workers Adds

Node.js API compatibility: crypto, tls, net, dns modules. Better support for frameworks expecting Node APIs.

Edge compute features:

• Durable Objects (real-time collaboration, WebSocket state)
• Cron Triggers (scheduled tasks at the edge)
• Queue Consumers (background job processing)
• Gradual Deployments (progressive rollouts)

Observability: Workers Logs with request-level detail, Logpush for analytics pipelines, Source Maps for debugging.

Does a Blog Need This?

Does a static blog need this? Probably not.

If you serve pre-built HTML, CSS, and JavaScript, both platforms are free and fast. The migration is trivial. What do you actually gain?

Form handling is the main reason to migrate. Contact forms, newsletter signups, comment APIs — you handle form posts without a separate backend service.

API endpoints like search, view counts, and reading time tracking. Workers builds lightweight APIs alongside your blog without a server.

Dynamic content like personalized pages, A/B testing, and geo-redirects. Useful for experimentation. Overkill for most blogs.

Skip Durable Objects unless you are building live comments or a collaborative editor. Skip Cron Triggers — most static site generators handle scheduled publishing at build time. Skip Queue Consumers entirely.

When to Migrate

Migrate if you plan to add comments, search, or dynamic features. Migrate if you want lightweight APIs for likes, subscriptions, or view counts. Migrate if you need better observability than Pages offers.

Stay on Pages if your blog is purely static and will remain so.

Why I Moved

I wanted newsletter signups without a third-party service. That gave Workers an actual job beyond serving the same static files.

If you are just serving markdown-to-HTML, do not bother. Pages works fine for static sites. The migration is simple enough to do anytime you need Workers features.