{"slug": "cloudflare-workers-accept-inbound-tcp-with-grpc-the-first-protocol-on-top", "title": "Cloudflare Workers Accept Inbound TCP, with gRPC the First Protocol on Top", "summary": "Cloudflare Workers can now accept inbound TCP connections via a new connect(socket) handler, with gRPC support as the first protocol built on top, announced during Agents Week. The capability, routed through Spectrum, enables full-duplex communication for any TCP-based protocol, though Workers themselves only support unary and server-streaming gRPC without containers, due to HTTP/2 stream-level constraints. The feature is in private beta, as Cloudflare does not use gRPC internally, relying instead on Cap'n Proto and Cap'n Web.", "body_md": "[Cloudflare Workers](https://developers.cloudflare.com/workers/) can now [accept inbound TCP connections](https://blog.cloudflare.com/grpc-workers/). Since the platform launched in 2017, a Worker could open outbound sockets to a database or a service, but it could only be a server for HTTP. A new connect(socket) handler removes that restriction, and [gRPC](https://grpc.io/) support is the first thing built on top of it.\n\nThe announcement landed during Agents Week, framed around voice AI, where low latency and a persistent bidirectional connection between client and model matter. The capability underneath is broader than that framing suggests.\n\nThree things shipped together, and they have different ceilings.\n\nThe connect(socket) handler accepts a raw inbound socket, routed to a Worker through [Spectrum](https://developers.cloudflare.com/spectrum/), Cloudflare's existing ingress proxy for non-HTTP traffic. A Worker can read and write the socket directly, hand it to another Worker, or pass it to a [Durable Object](https://developers.cloudflare.com/durable-objects/):\n\n```\nexport default {\n              async connect(socket): Promise<void> {\n                             const writer = socket.writable.getWriter();\n                             await writer.write(new TextEncoder().encode(\"Hello, world!\\n\"));\n                             await writer.close();\n              },\n} satisfies ExportedHandler;\n```\n\nFrom a Durable Object, the socket can go on to a [Container](https://developers.cloudflare.com/containers/) through getTcpPort(), which is where the full-duplex path ends. Cloudflare's examples include a Go gRPC echo server and a Python socketserver, both running unmodified. In the company's words, this opens the door to full-duplex communication between client and server running any program, in any language, for any TCP-based protocol.\n\nWorkers themselves get less. They can serve unary and server-streaming gRPC and call external gRPC servers, without a container, but not bidirectional streaming. The mechanism is translation rather than native support: developer code uses [gRPC-web](https://github.com/grpc/grpc-web), and Cloudflare converts incoming gRPC to gRPC-web and outgoing gRPC-web back to gRPC.\n\nThe reason is a platform constraint the post explains directly. [HTTP/2](https://developers.cloudflare.com/speed/optimization/protocol/http2/) splits requests into frames carrying stream IDs, and gRPC depends on that stream-level control for streaming, cancellation, flow control, and trailers. Web platform APIs like fetch() do not expose it. Browsers have the same problem, which is why gRPC-web exists, and Cloudflare has been converting gRPC to HTTP/1.1 inside its reverse proxy [since 2020](https://blog.cloudflare.com/road-to-grpc/) so that [WAF rules](https://developers.cloudflare.com/waf/) and Bot Management can inspect messages.\n\nSebastian Buzdugan raised the practical version of that constraint in [reply to Cloudflare's announcement](https://x.com/sebuzdugan/status/2084543600558264461), asking whether Workers expose enough backpressure control for gRPC streams, and noting that streaming edge cases are what decide whether an implementation holds. The post does not address it.\n\nThe practical effect is that existing clients need no changes. A Worker can serve mobile apps using [grpc-swift-2](https://github.com/grpc/grpc-swift) or [grpc-kotlin](https://github.com/grpc/grpc-kotlin), or sit in front of an existing gRPC backend the way Workers already sit in front of REST APIs. The server side takes a few lines with the open-source [@connectrpc/connect](https://connectrpc.com/) package.\n\nThe most candid part of the announcement is Cloudflare explaining why this is private beta rather than generally available. The company does not use gRPC internally:\n\nAt Cloudflare, we use [Cap'n Proto](https://capnproto.org/) and Cap'n Web and the JavaScript-native RPC system that is built into Cloudflare Workers instead of gRPC. And when we ship things, we always aim to be using them ourselves.\n\nThat is an unusual thing for a vendor to publish alongside a launch, and it sets an honest expectation. Cloudflare says it wants to work with a smaller set of gRPC developers first and make sure it has the implementation right before turning it on for everyone. Teams evaluating this should read it as a signal about maturity rather than as modesty.\n\nFor platform teams, the question is what the primitive enables beyond the announced use case. Workers have been constrained to HTTP for eight years, which ruled out entire categories of workload: message brokers, database proxies, custom binary protocols, anything expecting a socket. Passing a socket from Worker to Durable Object to Container makes the edge a termination point for arbitrary TCP, with routing logic in JavaScript ahead of it.\n\nThat routing position is worth noting. A Worker sees the connection before deciding where it goes, which is the same shape as an API gateway making decisions before forwarding a request, applied to raw sockets rather than HTTP. What a Worker can do with a socket in that position, in terms of inspection or policy, is not covered in the announcement.\n\nThe gRPC angle also lands at a specific moment. The [MCP 2026-07-28 specification](https://www.infoq.com/news/2026/08/mcp-stateless-gateway/) added gRPC as an optional transport alongside its HTTP one, and developers responding to that release noted how much of agent infrastructure amounts to rediscovering remote procedure call conventions that predate it. A protocol Google released nearly ten years ago keeps arriving as the answer for machine-to-machine traffic, including in systems designed around HTTP.\n\nEverything in the post is private beta behind a signup form, though Cloudflare's own [social copy](https://x.com/Cloudflare/status/2084293403328516571) announced that gRPC support \"is now available\" and described serving gRPC natively at the edge without translation layers. Readers arriving from that will find a narrower release than advertised. Cloudflare says UDP-based protocols are next.", "url": "https://wpnews.pro/news/cloudflare-workers-accept-inbound-tcp-with-grpc-the-first-protocol-on-top", "canonical_source": "https://www.infoq.com/news/2026/08/workers-inbound-tcp-grpc/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global", "published_at": "2026-08-29 09:55:00+00:00", "updated_at": "2026-08-29 10:18:31.578149+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["Cloudflare", "Cloudflare Workers", "Spectrum", "Durable Object", "Container", "gRPC", "Cap'n Proto", "Sebastian Buzdugan"], "alternates": {"html": "https://wpnews.pro/news/cloudflare-workers-accept-inbound-tcp-with-grpc-the-first-protocol-on-top", "markdown": "https://wpnews.pro/news/cloudflare-workers-accept-inbound-tcp-with-grpc-the-first-protocol-on-top.md", "text": "https://wpnews.pro/news/cloudflare-workers-accept-inbound-tcp-with-grpc-the-first-protocol-on-top.txt", "jsonld": "https://wpnews.pro/news/cloudflare-workers-accept-inbound-tcp-with-grpc-the-first-protocol-on-top.jsonld"}}