Cloudflare recommends migrating from Pages to Workers
14 days ago
- #Cloudflare
- #Serverless
- #Migration
- Cloudflare Workers allows deployment of full-stack applications, including front-end static assets, back-end APIs, and server-side rendered pages (SSR).
- Workers offers a broader set of features compared to Pages, such as Durable Objects, Cron Triggers, and comprehensive Observability.
- Migrating from Pages to Workers involves switching adapters, creating a Wrangler configuration file, and setting up static asset directories explicitly.
- For Single Page Applications (SPA) or custom 404 pages, explicit configuration is required in Workers, unlike the automatic detection in Pages.
- Workers requires manual exclusion of files like node_modules via an .assetsignore file, whereas Pages automatically excludes them.
- Full-stack frameworks using Pages Functions need to be updated to target Workers, and _worker.js files must be moved or ignored.
- Workers defaults to serving static assets before the Worker script unless configured otherwise with assets.run_worker_first.
- Workers provides customizable bindings for static assets, unlike the automatic ASSETS binding in Pages.
- Development commands change from wrangler pages dev/deploy to wrangler dev/deploy, with optional Vite plugin support.
- Preview environments in Workers require enabling preview URLs and non-production branch builds, with optional Cloudflare Access protection.
- _headers and _redirects files are supported natively in Workers if included in the static asset directory.
- Workers offers a workers.dev subdomain and supports custom domains and routes for deployment.
- Once migration is complete and verified, the Pages project can be deleted.
- A compatibility matrix highlights feature support differences between Workers and Pages, with some features requiring workarounds or being unsupported.