Compatibility flags·续3

{
    "observability": {
        "traces": {
            "enabled": true
        }
    }
}

Enable node:vm module

The enable_nodejs_vm_module flag enables the node:vm module stub in Workers.

This flag is automatically enabled for Workers using a compatibility date of 2025-10-01 or later when nodejs_compat is enabled.

See the Node.js documentation ↗︎ for more details about the node:vm API.

Enable node:console module

The enable_nodejs_console_module flag enables the node:console module in Workers.

This flag is automatically enabled for Workers using a compatibility date of 2025-09-21 or later when nodejs_compat is enabled.

See the Node.js documentation ↗︎ for more details about the node:console API.

Enable workflow entrypoint validation

When enable_validate_workflow_entrypoint is enabled, additional validation checks are performed to ensure that Workflows are defined and used correctly. This helps catch configuration errors at upload time rather than at runtime.

Enable node:fs module

The enable_nodejs_fs_module flag enables the node:fs module in Workers.

This flag is automatically enabled for Workers using a compatibility date of 2025-09-15 or later when nodejs_compat is enabled.

See the Node.js documentation ↗︎ for more details about the node:fs API.

Enable node:os module

The enable_nodejs_os_module flag enables the node:os module in Workers.

This flag is automatically enabled for Workers using a compatibility date of 2025-09-15 or later when nodejs_compat is enabled.

See the Node.js documentation ↗︎ for more details about the node:os API.

Enable process v2 implementation

When enabled after 2025-09-15, the enable_nodejs_process_v2 flag along with the nodejs_compat compat flag ensures a comprehensive Node.js-compatible process implementation, updating from the previous minimal process implementation that only provided the limited nextTick, env, exit, getBuiltinModule, platform and features properties.

To continue using the previous minimal implementation after the compat date, set the disable_nodejs_process_v2 flag instead.

Most Node.js-supported process properties are implemented where possible, with undefined exports for unsupported features. See the process documentation for Workers-specific implementation details.

Enable Node.js HTTP server modules

The enable_nodejs_http_server_modules flag enables the availability of Node.js HTTP server modules such as node:_http_server in Workers.

The disable_nodejs_http_server_modules flag disables the availability of these server modules.

This enables compatibility with Node.js libraries and existing code that use the standard Node.js HTTP server APIs. The available functionality includes:

• http.createServer() for creating HTTP servers
• http.Server class for server instances
• http.ServerResponse for handling server responses

This flag must be used in combination with the enable_nodejs_http_modules flag to enable full features of node:http.

This flag is automatically enabled for Workers using a compatibility date of 2025-09-01 or later when nodejs_compat is enabled.

See the Node.js documentation ↗︎ for more details about the Node.js HTTP APIs.

Enable node:http2 module

The enable_nodejs_http2_module flag enables the node:http2 module stubs in Workers.

This flag is automatically enabled for Workers using a compatibility date of 2025-09-01 or later when nodejs_compat is enabled.

See the Node.js documentation ↗︎ for more details about the node:http2 API.

Remove end-of-life Node.js APIs

When remove_nodejs_compat_eol is enabled, APIs that have reached End-of-Life in Node.js will be removed for Workers. When disabled, the APIs are present but might still be non-functional stubs.

This flag is a roll-up flag. As additional APIs reach EOL in specific Node.js versions, new version-specific compat flags are added (such as remove_nodejs_compat_eol_v22, remove_nodejs_compat_eol_v23, and remove_nodejs_compat_eol_v24) that are implied by this flag after their respective dates.

This flag is automatically enabled for Workers using a compatibility date of 2025-09-01 or later when nodejs_compat is enabled.

Remove Node.js 23.x end-of-life APIs

When remove_nodejs_compat_eol_v23 is enabled, APIs that reached end-of-life in Node.js 23.x (EOL June 2025) are removed.

This flag is automatically enabled when the remove_nodejs_compat_eol_v24 flag is enabled after 2025-09-01.

Strip Authorization header on cross-origin redirects

When strip_authorization_on_cross_origin_redirect is enabled, the Authorization header is automatically removed when following a redirect to a different origin. This behavior is required by the current Fetch API specification ↗︎.

This requirement was added to the Fetch spec in 2022, after Cloudflare Workers originally implemented its fetch handling. Workers did not originally implement this requirement, so the new behavior is gated behind a compatibility flag.

The old behavior was not inherently insecure, and could be desirable in some circumstances. For example, if an API that requires authorization wishes to redirect to a new hostname while having the client send along their credentials. Under the new behavior, such a redirect will not include credentials automatically. However, the old behavior could lead to unintentional credential leakage when redirecting to untrusted origins.

To retain the old behavior, set the retain_authorization_on_cross_origin_redirect flag.

Enable availability of node:http and node:https modules

The enable_nodejs_http_modules flag enables the availability of Node.js node:http and node:https modules in Workers (client APIS only).

The disable_nodejs_http_modules flag disables the availability of these modules.

This enables compatibility with Node.js libraries and existing code that use the standard node:http and node:https APIs for making HTTP requests. The available functionality includes:

• http.request() and https.request() for making HTTP/HTTPS requests
• http.get() and https.get() for making GET requests
• Request and response objects with standard Node.js APIs
• Support for standard HTTP methods, headers, and options

See the Node.js documentation ↗︎ for more details about the Node.js APIs.

Expose global MessageChannel and MessagePort

When the expose_global_message_channel flag is set, Workers will expose the MessageChannel and MessagePort constructors globally.

When the no_expose_global_message_channel flag is set, Workers will not expose these.

Disable global handlers for Python Workers

When the python_no_global_handlers flag is set, Python Workers will disable the global handlers and enforce their use via default entrypoint classes.

Enable cache: no-cache HTTP standard API

When you enable the cache_no_cache_enabled compatibility flag, you can specify the no-cache value for the cache property of the Request interface. When this compatibility flag is not enabled, or cache_option_disabled is set, the Workers runtime will throw a TypeError saying Unsupported cache mode: no-cache.

When this flag is enabled you can instruct Cloudflare to force its cache to revalidate the response from a subrequest you make from your Worker using the fetch() API:

When no-cache is specified:

• All requests have the headers Pragma: no-cache and Cache-Control: no-cache are set on them.
• Subrequests to origins not hosted by Cloudflare force Cloudflare's cache to revalidate with the origin.

Revalidating with the origin means that the Worker request will first look for a match in Cloudflare's cache, then:

• If there is a match, a conditional request is sent to the origin, regardless of whether or not the match is fresh or stale. If the resource has not changed, the cached version is returned. If the resource has changed, it will be downloaded from the origin, updated in the cache, and returned.
• If there is no match, Workers will make a standard request to the origin and cache the response.

Examples using cache: 'no-cache':

const response = await fetch("https://example.com", { cache: "no-cache" });

The cache value can also be set on a Request object.

const request = new Request("https://example.com", { cache: "no-cache" });
const response = await fetch(request);

Set the this value of EventTarget event handlers

When the set_event_target_this flag is se, Workers will set the this value of event handlers to the EventTarget instance that the event is being dispatched on. This is compliant with the specification.

When then no_set_event_target_this flag is set, Workers will not set the this value of event handlers, and it will be undefined instead.

Set forwardable email full headers

The original version of the headers sent to edgeworker were truncated to a single value for specific header names, such as To and Cc. With the set_forwardable_email_full_headers flag set, Workers will receive the full header values to the worker script.

Pedantic Web Platform Tests (WPT) compliance

The pedantic_wpt flag enables strict compliance with Web Platform Tests (WPT) in Workers. Initially this only effects Event and EventTarget APIs but will be expanded to other APIs in the future. There is no default enable date for this flag.

Bind AsyncLocalStorage snapshots to the request

The AsyncLocalStorage frame can capture values that are bound to the current request context. This is not always in the users control since we use the ALS storage frame to propagate internal trace spans as well as user-provided values. When the bind_asynclocalstorage_snapshot_to_request flag is set, the runtime binds the snapshot / bound functions to the current request context and will throw an error if the bound functions are called outside of the request in which they were created.

The do_not_bind_asynclocalstorage_snapshot_to flag disables this behavior.

Throw on unrecognized import assertions

The throw_on_unrecognized_import_assertion flag controls how Workers handle import attributes that are not recognized by the runtime. Previously, Workers would ignore all import attributes, which is not compliant with the specification. Runtimes are expected to throw an error when an import attribute is encountered that is not recognized.

When the ignore_unrecognized_import_assertion flag is set, Workers will ignore unrecognized import attributes.

Enable eval during startup

When the allow_eval_during_startup flag is set, Workers can use eval() and new Function(text) during the startup phase of a Worker script. This allows for dynamic code execution at the beginning of a Worker lifecycle.

When the disallow_eval_during_startup flag is set, using eval() or new Function(text) during the startup phase will throw an error.

Enable Request.signal for incoming requests