Cloudflare is merging Pages into Workers. For static sites, the migration is a one-line config change. The real question: do you need to migrate at all?

What It Costs

Static hosting is free on both platforms. Page count does not matter.

Pages charges for builds:

• Free: 500 builds/month
• Pro: $20/month for 5,000 builds

Workers charges for server-side execution:

• Free: 100,000 requests/day
• Paid: $5/month for 10M requests

For a static blog: both cost $0/month unless you exceed 500 builds or add dynamic features. I have been on the free tier for years.

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:

Required:

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

Optional but recommended:

• 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 the permissions above
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?

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.

My Take

I migrated because I wanted newsletter signups without third-party services. The migration took 5 minutes. Most of that was waiting for deployment.

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.