Cloudflare Workers: Node.js Is Default Now — Act Fast

Cloudflare just made Node.js compatibility the default for every new Worker. As of compatibility date 2026-08-04, node:crypto, node:buffer, node:stream, node:http, and two dozen more Node.js APIs load without a single flag in your config. If you have an old nodejs_compat entry in your wrangler.toml, it still works — it’s just redundant now. And if you’re bumping an older project to the new date threshold, one behavior change is waiting to catch you off guard.

What Actually Changed

Any Worker with a compatibility_date of 2026-08-04 or later gets both nodejs_compat and nodejs_compat_v2 enabled automatically. That covers virtually every Node.js built-in API the Workers runtime supports:

• node:assert, node:buffer, node:crypto (including scrypt and scryptSync)
• node:dns, node:events / EventEmitter
• node:fs (partial — no real filesystem; map to KV and R2 for persistence)
• node:http (partial — built on fetch() under the hood; no Agent API or trailers)
• node:net, node:path, node:stream, node:url, node:util
• AsyncLocalStorage

Workers on older compatibility dates are completely unaffected — their behavior is frozen to the date they declared. Only projects actively bumping to the new threshold feel this change. See the official Cloudflare changelog entry for the full details.

npm Packages That Stop Needing Special Config

Before this change, packages that depend on Node.js core APIs required an explicit nodejs_compat flag or they’d fail with cryptic import errors. That list is long: body-parser, jsonwebtoken, pg, got, passport, mongodb, and knex all fall into it. Now they work in any new Worker without touching your config. That’s the real productivity win here — the Node ecosystem just became a first-class citizen on the edge.

The One Thing That Can Break

There’s a behavior change worth knowing about before you bump your date: arrays passed as fetch body content are now treated as iterables rather than being stringified. This landed as default-on via the fetch_iterable_type_support_override_adjustment compatibility flag back in January 2026, so most projects have already absorbed it — but if you’re jumping from a much older compatibility date, it’s the gotcha to audit for first.

That array is now streamed as an iterable, not converted to a string. The fix is explicit: serialize it yourself, or add no_fetch_iterable_type_support_override_adjustment to your compatibility flags to opt out.

The New Module Registry (Opt-In, Worth Enabling)

Separate from the Node.js default change, Cloudflare also published a detailed post on the new module registry this week. It’s opt-in via the new_module_registry flag with no default-on date set yet, but it carries the most technical depth of the two updates.

The old registry had two design flaws. It compiled your entire Worker bundle at startup — whether or not a given module ever got imported. And it kept a private copy of every module per V8 isolate; Workers runs multiple isolates per Worker to spread load across CPU cores, meaning it compiled the same source multiple times and held multiple copies in memory.

The new registry fixes both. Modules compile lazily when first imported and share a cache across isolates. It also resolves specifiers as real URLs, which finally makes import.meta.url, import.meta.resolve(), and patterns like createRequire(import.meta.url) work correctly. Node.js-style require(esm) rules and WebAssembly source phase imports round out the new capabilities.

Cloudflare is being appropriately cautious about making this default — broken module resolution would be a serious regression — but the performance and compatibility gains are real. Enable it in staging, validate, then ship it.

What to Do Before Your Next Deploy

If you’re bumping a project’s compatibility date to anything at or after 2026-08-04, here is the checklist:

1. Audit array-as-body patterns. Search your codebase for fetch calls that pass arrays as the body. Stringify explicitly or opt out with the compatibility flag.
2. Remove redundant compat flags. nodejs_compat and nodejs_compat_v2 in your config are now no-ops for these dates. Cleaning them up reduces config noise.
3. Profile startup with Wrangler. Run wrangler check startup before and after to verify the date bump does not affect your bundle size or startup time.
4. Try the new module registry. Add new_module_registry to compatibility_flags, test locally with wrangler dev, and check whether any import patterns change. If clean, keep it.

The Bigger Picture

This change is three years in the making. Cloudflare started shipping Node.js polyfills in 2023 with AsyncLocalStorage and EventEmitter, added the full v2 flag system in 2024, and has now made the whole thing default. The message is clear: Workers is no longer a platform where you carefully port code to web APIs. It’s a platform where existing Node.js code runs, mostly as-is, at the edge.

The remaining gaps — Agent API in node:http, real filesystem semantics in node:fs — are known and on the roadmap. But for the vast majority of server-side JavaScript workloads, the friction is gone. The new module registry is the next flag worth flipping.