How to Deploy an Astro Site to Cloudflare Workers
Ship a static or server-rendered Astro site to Cloudflare Workers with Wrangler — adapter setup, wrangler.jsonc, nodejs_compat, secrets, custom domains and the errors you hit on the first deploy.
A runtime that is not Node, deployed with one command, billed by CPU time.
Workers run JavaScript and WebAssembly on Cloudflare’s edge, close to whoever
made the request. The runtime implements web standard APIs rather than Node’s,
which is the first thing to internalise: fetch, Request, Response and Web
Crypto are there, and fs is not.
Reach for Workers when the work is request-shaped and short — routing, auth checks, API aggregation, server-rendered HTML, edge redirects. Reach for something else when you need long-lived connections, heavy CPU per request, or a filesystem.
Static sites are the easiest case. If every route prerenders, the build output is just files served as Workers static assets, and no Worker code runs at all. Adding server-rendered routes means an adapter and an entry point, and that is where the configuration surface appears.
Three things reliably cost people an afternoon. The nodejs_compat
compatibility flag, without which any dependency importing a node: built-in
fails. The script size limit, which a single heavy dependency in a server route
can breach. And secrets, which must be pushed with wrangler secret put —
values in a local .dev.vars file are never uploaded, so a Worker that runs
locally can still 500 in production.
The billing model is CPU time, not wall-clock time. Waiting on a subrequest is cheap; parsing a large payload is not. That distinction is worth knowing before you design a route that does five sequential fetches.
Start here
Ship a static or server-rendered Astro site to Cloudflare Workers with Wrangler — adapter setup, wrangler.jsonc, nodejs_compat, secrets, custom domains and the errors you hit on the first deploy.
A reading order that builds Workers knowledge in the sequence it is actually needed.
Failure modes that come up repeatedly with Workers, and where each one is solved.
Ship a static or server-rendered Astro site to Cloudflare Workers with Wrangler — adapter setup, wrangler.jsonc, nodejs_compat, secrets, custom domains and the errors you hit on the first deploy.
Ship a static or server-rendered Astro site to Cloudflare Workers with Wrangler — adapter setup, wrangler.jsonc, nodejs_compat, secrets, custom domains and the errors you hit on the first deploy.
Workers. Cloudflare positions Workers with static assets as the default for new projects and new platform features land there first. Existing Pages deployments keep working, so there is no urgency to migrate.
No. It implements web standard APIs — fetch, Request, Response, Web Crypto — and exposes a subset of Node built-ins behind the `nodejs_compat` flag. Code that assumes `process`, filesystem access or long-lived state needs changes.
Which runtime behaviours your Worker gets. Cloudflare gates changes behind it so an existing Worker does not change under you. Pin it, and bump it in its own commit with its own deploy.