Since 4 August 2026, Cloudflare enables Node.js compatibility by default for Workers with a compatibility_date of 2026-08-04 or later. New projects do not need nodejs_compat or nodejs_compat_v2. Workers pinned to an earlier date are unchanged and can keep their old behavior or opt in with the established flags.
The announcement simplifies configuration, but a date update is still a runtime migration for an existing service. An npm package may begin loading where it previously failed, a stub may become a partial implementation, and bundle, startup, or error behavior can move. Do not combine the compatibility-date update, a dependency upgrade, and an application redesign in one production release.
Cloudflare’s 4 August announcement and the current Node.js compatibility reference
What “enabled by default” actually provides
Workers exposes Node interfaces in two forms. Some are implemented natively in the runtime. Others are polyfills or import-only stubs added by Wrangler, so an import can succeed while an unsupported method throws when called. Cloudflare currently marks Buffer, Crypto, Events, and File System as natively supported, while Console, DNS, and other surfaces are partial.
That distinction matters when evaluating an npm dependency. Successful compilation is not compatibility proof. A package may reach the unsupported branch only during a network failure, file operation, stream cancellation, or rare authentication path. Read the supported-API table and exercise the functions your product actually uses in the Workers runtime.
A current project can use a minimal configuration:
{
"name": "customer-api",
"main": "src/index.ts",
"compatibility_date": "2026-08-29"
}There is no benefit in adding redundant positive flags. If a documented constraint requires disabling both compatibility layers on a recent date, Cloudflare instructs developers to add no_nodejs_compat and no_nodejs_compat_v2 together. Treat that as a reviewed exception with an owner and removal date, not an unexplained permanent setting.
Treat compatibility_date as an operating contract
Cloudflare uses the date to opt a Worker into backward-incompatible runtime changes available up to that point. Existing deployments remain stable while each project chooses when to accept new behavior. Old dates remain supported, but staying frozen forever separates the service from current APIs and makes modern documentation less representative of the runtime you operate.
Review every compatibility flag between the old and new dates, not only the Node announcement. The new date takes effect on the next Wrangler deployment. Isolate it in a controlled release:
- Pin dependencies, Wrangler, and the build environment.
- Change only the compatibility date on a dedicated branch.
- Run unit, integration, and contract tests.
- Compare bundle size, startup, CPU, latency, and errors.
- Deploy a version or staging environment, then limited traffic.
- Keep the previous Worker version and a tested rollback path.
A 200 response from one endpoint is not sufficient. Authentication, streaming, timeouts, crypto, outbound connections, and error contracts need to remain correct.
Evaluate npm packages by behavior
The default reduces the need for forks and custom polyfills, especially when packages use node:crypto, node:buffer, node:stream, node:net, node:dns, node:fs, or node:http. It does not turn Workers into a traditional Node server or provide a persistent operating-system environment.
Consider node:fs. Workers provides a virtual file system with read-only bundle files under /bundle and request-local writes under /tmp. Temporary files are not available to concurrent or later requests. They live in memory and count against the 128 MB Worker limit. File watching and glob APIs are not implemented, and timestamps currently resolve to the Unix epoch. A package expecting durable disk or POSIX permissions may build cleanly and still lose data.
Build a review matrix for sensitive dependencies:
| Question | Acceptance evidence |
|---|---|
| Which Node modules are imported? | Dependency trace or bundle report |
| Native, partial, or stub support? | Dated Cloudflare support table |
| Which branch does production use? | Integration test of the real flow |
| Files, sockets, or long streams? | Limit, failure, and retry tests |
| Fits 128 MB and plan CPU? | Staging measure and production canary |
Do not rely only on a package README saying it is edge-compatible. It may refer to a different version, runtime, or code path.
Cost and business impact
Cloudflare lists no separate charge for Node.js compatibility. Billing remains Workers billing based on requests, CPU, and attached services. On 29 August 2026, Workers Free includes 100,000 requests per day with 10 ms CPU per invocation. Workers Paid has a $5 monthly account minimum and includes 10 million requests plus 30 million CPU milliseconds per month, followed by $0.30 per additional million requests and $0.02 per additional million CPU milliseconds. Enterprise terms depend on the contract.
Compatibility can still change indirect cost. A large dependency can consume more startup or CPU, a polyfill can do more work than a native Web API, and temporary files can pressure the memory cap. Removing bespoke adapters can reduce maintenance and defects. Compare cost per successful request, including retries and startup behavior, rather than promising savings from a cleaner config file.
The business value is broader library choice and less compatibility code. That can speed delivery of APIs, middleware, and content processing, but it does not remove data-residency, secret-management, storage, or lock-in decisions. Moving a Node service to Workers should be driven by its workload, not only by successful imports.
A production migration gate
Inventory the current configuration
Record date and flags for every environment. Find drift across wrangler.jsonc, wrangler.toml, dashboard settings, and CI. Confirm that preview and production use the intended configuration.
Review behavior between dates
Open the compatibility-flags reference and list everything enabled between the two dates. Classify each item as unused, test-required, or blocking. Do not hide conflicts behind negative flags without an issue and removal plan.
Test failure paths
Exercise timeout, DNS failure, stream cancellation, invalid crypto input, and unexpectedly large files. Verify error types and messages used by monitoring. Repeat critical checks locally and on a Cloudflare version because local CPU profiles do not perfectly represent the production platform.
Roll out gradually
Deploy an immutable version and monitor 5xx, CPU, startup, latency, and bundle size. Run synthetic requests through sensitive flows. If output or error rates move outside the gate, route traffic back to the previous version and diagnose away from production.
Compatibility and availability limits
- The default applies across Workers Free and Paid for compatibility dates of 2026-08-04 or later. Cloudflare documents no country-specific restriction for this feature. Enterprise contract terms still need separate review.
- Support is a Node.js subset. Some APIs are partial or stubs, so verify each imported module.
- Normal platform limits remain, including 128 MB memory and plan-specific CPU, subrequest, and script-size ceilings.
node:fsis virtual, not durable storage. Use KV, D1, R2, or Durable Objects according to the data model instead of depending on/tmp.- A recent date may activate changes unrelated to Node compatibility.
- Workers dated 2026-08-03 or earlier do not change automatically and can still opt in with
nodejs_compat.
Practical recommendation
For a new project, use today’s date without redundant positive flags and test every dependency in the actual Workers runtime. For an older service, make the date upgrade a standalone release with a measurable comparison and rollback. Neither indefinite postponement nor a large combined rewrite produces useful evidence.
When building an API or site on Cloudflare, the goal is not to run a Node package at any cost. Prefer the smallest clear layer, use native Web APIs when they fit, and adopt Node compatibility where it reduces maintenance risk while passing real platform limits.
Sources and review date
- Node.js compatibility enabled by default, 4 August 2026
- Supported and partial Node.js API reference
- Compatibility-date policy
node:fsvirtual file-system behavior- Current Workers pricing and inclusions
- Status, pricing, availability, and limits were reviewed on 29 August 2026.