Workers Runtime versus Node.js

Three compatibility states

For a new Worker whose compatibility date is 2026-08-04 or later, Node.js compatibility and v2 are enabled by default and the official guidance says to omit the positive flag. Do not blindly rewrite an older project: preserve its date, run regression tests, and advance the date deliberately.

Think in edge primitives

export default {
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    const upstream = await fetch(`https://api.example.com${url.pathname}`);
    return new Response(upstream.body, upstream);
  },
};

This uses Request, Response, URL, and fetch; it assumes no filesystem, resident process, or mutable memory shared reliably across requests.

Review AI-generated code

1. Search for fs, net, child_process, native binaries, and server-listen code.
2. Classify each API against the current Node compatibility table; an import is not evidence.
3. Execute success and failure branches with wrangler dev.
4. Update compatibility dates in an isolated change with behavior notes.

Continue across runtimes and toolchains

• When Bun manages dependencies and invokes Wrangler, deployed code still executes in workerd. The Bun guide to Cloudflare Workers focuses on that boundary.
• Deno and Workers expose many Web APIs, but their permission, persistence, deployment, and Node compatibility models are not interchangeable. Read Deno versus Node and Bun, then bring each dependency back to this page for verification.

Use the related technology guide network for the complete cross-site map.

Primary sources

• Runtime APIs
• Node.js compatibility
• Compatibility dates