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.
If you're still unsure what use-cases are best for Pages and when you should use Workers with assets, we broadly recommend:
- Pages for static sites or simple applications (such as personal blogs or websites).
- Workers for building both static sites and full stack applications, since you can take advantage of the full developer platform (such as Queues, Durable Objects, and more).
We will continue to work to close the gaps between Workers and Pages, as well as provide a migration path.
Legend
โ
: Supported
โณ: Coming soon
๐ก: Unsupported, workaround available
โ: Unsupported
Think something is missing from this list? Open a pull request โ or create a GitHub issue โ.
-
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
run_worker_firstoption, 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
_redirectssupport), 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. โฉ