Node.js HTTP APIs arrive on Cloudflare Workers

Cloudflare Workers now supports the node:http client and server APIs, letting developers run familiar Node.js application stacks—Express.js, Koa, and others—on the edge without rewriting their codebases. The move extends the existing nodejs_compat compatibility flag to cover HTTP interfaces, so existing patterns and frameworks can be deployed globally with Workers' scaling and zero-cold-start model intact.

Adapting Node HTTP to a managed serverless runtime

Workers doesn't give developers a direct TCP socket. Networking is fully managed outside the runtime by Cloudflare's infrastructure—services like the Open Egress Router (OER) and Pingora handle connection pooling, warm connections, egress IPs, and TLS. That's precisely why certain Node.js APIs can't be supported: those decisions are made at the system level for performance and security. As a developer, that means you get enterprise-grade networking without managing any of the underlying connection details.

To bridge the gap, Cloudflare implemented the core node:http APIs on top of the web-standard technologies Workers already relies on—notably the fetch() API.

Client-side support

The client implementation covers the essential interfaces you'd expect, including http.get() and http.request(). These are built on the native fetch() API to keep performance high while preserving Node.js compatibility.

  • Standard HTTP methods (GET, POST, PUT, DELETE, etc.)
  • Request and response headers
  • Request and response bodies
  • Streaming responses
  • Basic authentication

Some limitations remain. The Agent API is present but no-ops, Trailers, early hints, 1xx responses, and TLS-specific options are not supported—the runtime handles TLS automatically.

Bridging server APIs into the Worker model

Writing HTTP servers in Workers instead of traditional TCP servers requires a different integration strategy. When you create an HTTP server via http.createServer() and call listen(port), the server isn't bound to a socket. Instead, it registers itself in an internal table that uses the port number as the identifier, acting as a bridge between createServer executions and incoming fetch requests.

Developers have two ways to connect Worker requests to their Node.js-style server.

Manual integration uses handleAsNodeRequest, which lets you tie Node.js server traffic alongside other worker entrypoints like fetch, scheduled, or queue. This option is useful when you need to integrate with other Workers features—KV, Durable Objects, R2—handle some routes with custom logic while delegating others to the Node server, or apply custom middleware and request processing.

For simpler cases, the httpServerHandler function automates the integration. It's ideal when you don't need any Workers-specific features and just want the Node server to handle all incoming requests.

Framework compatibility

Supporting node:http opens the door for popular Node.js frameworks on Workers. Express.js and Koa.js are explicitly supported. Any middleware that relies on unsupported APIs may not behave exactly as expected. Developers are asked to open an issue in the workerd repository if they hit such cases.

The node:http and node:https APIs require the nodejs_compat compatibility flag with a compatibility date later than 08-15-2025. Whether the goal is migrating existing Node.js services or building new ones at the edge, these APIs remove a significant barrier to bringing traditional server patterns into the Workers runtime.