Cloudflare Workers turns on Node.js APIs by default, raises the bundle limit to 64 MiB, and adds a new module registry behind a flag

Cloudflare published a rewrite of the Workers runtime module registry on 9 September 2026. The same post announces two related changes: Node.js runtime APIs are now enabled by default in Workers, and the per-Worker bundle limit has been raised to 64 mebibytes on all plans, up from the previous ceiling.

What is on today

Cloudflare writes that the Workers runtime "now supports every stable API from Node.js that you might want to use in a serverless context, and these APIs are now enabled by default." The 64 MiB bundle limit ships alongside that and applies to every plan, not only paid ones. Both changes take effect without a compatibility flag.

What is behind the new_module_registry flag

The module registry rewrite is opt-in through the new_module_registry compatibility flag, and Cloudflare states there is no default-on date for it yet. Once turned on, a Worker gets URL-based specifiers, import.meta.url and import.meta.main, import.meta.resolve(), standards-conformant require(esm) semantics that follow Node.js including the ERR_REQUIRE_ASYNC_MODULE restriction on top-level await, validated import attributes with type: 'json' as the only accepted value today, and source-phase imports for WebAssembly through import.source().

Two behaviours worth flagging because they can change existing code. Query strings and fragments on a specifier now produce distinct module instances following browser module-identity rules, so ./counter.js?a and ./counter.js?b load the same source but keep separate top-level state. And any import attribute other than type is now a hard error instead of being silently ignored, which Cloudflare says fixes a spec violation in the previous implementation.

The rewrite also lets the runtime compile modules lazily rather than compiling every module in a bundle up front, and share compiled code across V8 isolate replicas of the same Worker rather than holding a private copy per isolate. Cloudflare frames both as steps toward letting bundlers like Rolldown do less work and letting the runtime handle more of the module resolution itself.

What stays the same

Cloudflare says the existing module registry is not going away, and existing Workers continue to run without changes. The new registry sits behind a flag rather than replacing the old one, so a team can adopt it Worker by Worker.

For anyone deploying a Node.js server to Workers, the two default-on changes matter first: an app that hit the previous size ceiling can now target Workers as a real deployment surface, and a codebase that already assumed a Node.js runtime does not need a compatibility flag to start. The registry rewrite is a second decision, worth taking when the code that was working around missing import.meta.url, require(esm), or WebAssembly source-phase imports becomes easier to delete than to keep.

Source

• How we rebuilt Cloudflare Workers' module registry for Node.js compatibility