To enable built-in Node.js APIs and polyfills, add the nodejs_compat compatibility flag to yourWrangler configuration file. This also enables nodejs_compat_v2 as long as your compatibility date is 2024-09-23 or later.Learn more about the Node.js compatibility flag and v2.
To use the HTTPS client-side methods (https.get,https.request, etc.), you must enable theenable_nodejs_http_modules compatibility flag in addition to thenodejs_compat flag.
This flag is automatically enabled for Workers using acompatibility date of2025-08-15 or later whennodejs_compat is enabled. For Workers using an earlier compatibility date, you can manually enable it by adding the flag to yourwrangler.toml:
compatibility_flags=["nodejs_compat","enable_nodejs_http_modules"]To use the HTTPS server-side methods (https.createServer,https.Server,https.ServerResponse), you must enable theenable_nodejs_http_server_modules compatibility flag in addition to thenodejs_compat flag.
This flag is automatically enabled for Workers using acompatibility date of2025-09-01 or later whennodejs_compat is enabled. For Workers using an earlier compatibility date, you can manually enable it by adding the flag to yourwrangler.toml:
compatibility_flags=["nodejs_compat","enable_nodejs_http_server_modules"]To use both client-side and server-side methods, enable both flags:
compatibility_flags=["nodejs_compat","enable_nodejs_http_modules","enable_nodejs_http_server_modules"]An implementation of the Node.js`https.get' ↗ method.
Theget method performs a GET request to the specified URL and invokes the callback with the response. This is a convenience method that simplifies making HTTPS GET requests without manually configuring request options.
Becauseget is a wrapper aroundfetch(...), it may be used only within an exported fetch or similar handler. Outside of such a handler, attempts to useget will throw an error.
import{get} from"node:https";exportdefault{asyncfetch(){const{promise,resolve,reject}=Promise.withResolvers();get("https://example.com",(res)=>{letdata="";res.setEncoding("utf8");res.on("data",(chunk)=>{data+=chunk;});res.on("end",()=>{resolve(newResponse(data));});res.on("error",reject);}).on("error",reject);returnpromise;},};The implementation ofget in Workers is a wrapper around the globalfetch API ↗and is therefore subject to the samelimits ↗.
As shown in the example above, it is necessary to arrange for requests to be correctlyawaited in thefetch handler using a promise or the fetch may be canceled prematurelywhen the handler returns.
An implementation of the Node.js`https.request' ↗ method.
Therequest method creates an HTTPS request with customizable options like method, headers, and body. It provides full control over the request configuration and returns a Node.jsstream.Writable ↗ for sending request data.
Becauseget is a wrapper aroundfetch(...), it may be used only within an exported fetch or similar handler. Outside of such a handler, attempts to useget will throw an error.
The request method accepts all options fromhttp.request with some differences in default values:
protocol: defaulthttps:port: default443agent: defaulthttps.globalAgent
import{request} from"node:https";import{strictEqual,ok} from"node:assert";exportdefault{asyncfetch(){const{promise,resolve,reject}=Promise.withResolvers();constreq=request("https://developers.cloudflare.com/robots.txt",{method:"GET",},(res)=>{strictEqual(res.statusCode,200);letdata="";res.setEncoding("utf8");res.on("data",(chunk)=>{data+=chunk;});res.once("error",reject);res.on("end",()=>{ok(data.includes("User-agent"));resolve(newResponse(data));});},);req.end();returnpromise;},};The following additional options are not supported:ca,cert,ciphers,clientCertEngine (deprecated),crl,dhparam,ecdhCurve,honorCipherOrder,key,passphrase,pfx,rejectUnauthorized,secureOptions,secureProtocol,servername,sessionIdContext,highWaterMark.
An implementation of the Node.jshttps.createServer ↗ method.
ThecreateServer method creates an HTTPS server instance that can handle incoming secure requests. It's a convenience function that creates a newServer instance and optionally sets up a request listener callback.
import{createServer} from"node:https";import{httpServerHandler} from"cloudflare:node";constserver=createServer((req,res)=>{res.writeHead(200,{"Content-Type":"text/plain"});res.end("Hello from Node.js HTTPS server!");});server.listen(8080);exportdefaulthttpServerHandler({ port:8080});ThehttpServerHandler function integrates Node.js HTTPS servers with the Cloudflare Workers request model. When a request arrives at your Worker, the handler automatically routes it to your Node.js server running on the specified port. This bridge allows you to use familiar Node.js server patterns while benefiting from the Workers runtime environment, including automatic scaling, edge deployment, and integration with other Cloudflare services.
Failing to callclose() on an HTTPS server may result in the server being leaked. To prevent this, callclose() when you're done with the server, or use explicit resource management:
import{createServer} from"node:https";await usingserver=createServer((req,res)=>{res.end("Hello World");});// Server will be automatically closed when it goes out of scopeAn implementation of the Node.jshttps.Agent ↗ class.
AnAgent ↗ manages HTTPS connection reuse by maintaining request queues per host/port. In the Workers environment, however, such low-level management of the network connection, ports, etc, is not relevant because it is handled by the Cloudflare infrastructure instead. Accordingly, the implementation ofAgent in Workers is a stub implementation that does not support connection pooling or keep-alive.
An implementation of the Node.jshttps.Server ↗ class.
In Node.js, thehttps.Server class represents an HTTPS server and provides methods for handling incoming secure requests. In Workers, handling of secure requests is provided by the Cloudflare infrastructure so there really is not much difference between usinghttps.Server orhttp.Server. The workers runtime provides an implementation for completeness but most workers should probably just usehttp.Server.
import{Server} from"node:https";import{httpServerHandler} from"cloudflare:node";constserver=newServer((req,res)=>{res.writeHead(200,{"Content-Type":"application/json"});res.end(JSON.stringify({ message:"Hello from HTTPS Server!"}));});server.listen(8080);exportdefaulthttpServerHandler({ port:8080});The following differences exist between the Workers implementation and Node.js:
- Connection management methods such as
closeAllConnections()andcloseIdleConnections()are not implemented due to the nature of the Workers environment. - Only
listen()variants with a port number or no parameters are supported:listen(),listen(0, callback),listen(callback), etc. - The following server options are not supported:
maxHeaderSize,insecureHTTPParser,keepAliveTimeout,connectionsCheckingInterval - TLS/SSL-specific options such as
ca,cert,key,pfx,rejectUnauthorized,secureProtocolare not supported in the Workers environment. If you need to use mTLS, use themTLS binding.
Because the Workers implementation ofnode:https is a wrapper around the globalfetch API, there are some differences in behavior compared to Node.js:
Connectionheaders are not used. Workers will manage connections automatically.Content-Lengthheaders will be handled the same way as in thefetchAPI. If a body is provided, the header will be set automatically and manually set values will be ignored.Expect: 100-continueheaders are not supported.- Trailing headers are not supported.
- The
'continue'event is not supported. - The
'information'event is not supported. - The
'socket'event is not supported. - The
'upgrade'event is not supported. - Gaining direct access to the underlying
socketis not supported. - Configuring TLS-specific options like
ca,cert,key,rejectUnauthorized, etc, is not supported.