Workers vs. Pages (compatibility matrix)
You can deploy full-stack applications, including front-end static assets and back-end APIs, as well as server-side rendered pages (SSR), to both Cloudflare Workers and Pages. The compatibility matrix below shows which features are available for each, to help you choose whether to build with Workers or Pages. Unless otherwise stated below, what works in Pages works in Workers, and what works in Workers works in Pages. Think something is missing from this list? Open a pull request โ or create a GitHub issue โ.
We plan to bridge the gaps between Workers and Pages and provide ways to migrate your Pages projects to Workers.
Legend
โ
: Supported
โณ: Coming soon
๐ก: Unsupported, workaround available
โ: Unsupported
-
Similar to 3, to customize the HTTP headers that are returned by static assets, you can use Service bindings to connect a Worker in front of the Worker with assets. โฉ
-
Middleware can be configured via the
experimental_serve_directly
option, but is charged as a normal Worker invocation. We plan to explore additional related options in the future. โฉ -
You can handle redirects by adding code to your Worker (a community package โ is available for
_redirects
support), or you can use Bulk Redirects. โฉ -
To use Durable Objects with your Cloudflare Pages project, you must create a separate Worker with a Durable Object and then declare a binding to it in both your Production and Preview environments. Using Durable Objects with Workers is simpler and recommended. โฉ
-
Workers supports popular frameworks, many of which implement file-based routing. โฉ
-
Everything that is possible with Pages Functions can also be achieved by adding code to your Worker or by using framework-specific plugins for relevant third party tools. โฉ