Inbound TCP Lands on Cloudflare Workers: Full-Duplex gRPC at the Edge

Cloudflare Reverses the Flow: Inbound TCP Now Powers Real-Time gRPC at the Edge

Cloudflare’s engineering team has opened a new chapter for serverless edge computing, introducing inbound TCP connections to Workers and Durable Objects for the first time.

The move—currently in private beta—gives developers a direct path to run full-duplex gRPC servers on the platform, eliminating years of workarounds that relied on WebSocket shims or external infrastructure.

At the center of the launch sits a new connect() handler, which lets a Worker accept raw TCP sockets routed through Spectrum, Cloudflare’s proxy for non-HTTP traffic.

We’re introducing this in private beta.

Together with gRPC-to-gRPC-web conversion inside Workers, the announcement reshapes what’s possible for latency-sensitive voice AI, real-time assistants, and any workload that demands persistent bidirectional streaming close to users.

The Three-Part Architecture That Turns Workers Into Full-Stack gRPC Machines

The launch, as detailed in Cloudflare’s announcement, isn’t a single feature; it’s a three-legged scaffold that gives developers complete control over how TCP and gRPC traffic flows across Cloudflare’s network.

The first leg is the connect() handler on Workers and Durable Objects.

Instead of being limited to outbound TCP connections, a Worker can now receive an inbound socket, read from it, and write back—opening the door to any TCP-based protocol on the server side.

Developers can pass that socket to a Durable Object for stateful session handling, or even forward it straight into a Container running a custom gRPC server written in Go, Python, or any language.

A new Spectrum application type makes this possible by binding a domain’s raw TCP ingress directly to a Worker, so Cloudflare’s global proxy sits in front of the entire stream without translating it to HTTP.

The second leg fills a gap that kept heavy gRPC workloads off the edge: true bi-directional streaming inside Containers.

With the socket passing described above, a gRPC server container can maintain a single persistent connection where both client and server send messages simultaneously, exactly the pattern that modern voice AI pipelines demand.

Because the container runs within Cloudflare’s infrastructure, the stream benefits from the same ultra-low latency that the network offers to HTTP requests—no extra hop to an external origin.

The third leg handles the simpler, more ubiquitous gRPC use cases without a container at all.

Workers now transparently convert incoming gRPC-web requests to full gRPC, and outgoing gRPC-web calls to native gRPC.

Using the open-source @connectrpc/connect library, a developer can write a unary or server-streaming gRPC backend—or a client that talks to an external gRPC API—entirely inside a Worker, while mobile apps and other native gRPC clients continue to speak their standard protocol.

This translation layer, refined since Cloudflare first adopted gRPC-web internally in 2020, also brings the security stack—WAF rules, Bot Management—to gRPC traffic as a built-in benefit.

The Performance Math: Why a 330-Location Network Changes the Voice AI Equation

Real-time voice interfaces have a brutal latency budget.

A conversational assistant that feels natural must keep end-to-end audio delay below 150 milliseconds, ideally far lower.

Traditional architectures often funnel voice streams to a centralized gRPC inference service that sits in a handful of cloud regions, adding tens to hundreds of milliseconds of round-trip time before the first model inference even begins.

Cloudflare’s network of more than 330 cities changes that arithmetic by letting developers colocate the gRPC server, the Worker logic, and even the model container at a point of presence that sits physically near the user.

This isn’t a marginal optimization—it can turn a 150ms baseline into 30ms, the difference between a stilted interaction and a fluid conversation.

The strategic decision to launch as a private beta signals a noteworthy caution from a company that famously dogfoods its own stack.

Cloudflare’s internal RPC of choice is Cap’n Proto, not gRPC.

By working with a smaller set of gRPC-native developers first, the team acknowledges that real-world voice pipelines, mobile protocol stacks, and the quirks of HTTP/2 flow control introduce complexity that only battle-tested deployments can surface.

For the performance-conscious architect, this restraint is actually a strong signal: the platform isn’t rushing a half-baked feature to general availability, but methodically hardening a capability that touches the most latency-critical layer of the stack.

Competitively, raw TCP ingress and container-native gRPC streaming push Cloudflare’s serverless offering into territory that other edge compute providers have not matched.

Platforms that rely exclusively on HTTP-based listeners or that limit the runtime to JavaScript often force developers to front gRPC workloads with a proxy or to abandon bi-directional streams entirely.

By merging Spectrum’s proxy, the socket handler, and Containers, Cloudflare erases that middleman, making the edge a viable first-class deployment target for the entire class of real-time connection-oriented applications.

Edge-Native Streaming Becomes the New Baseline

Voice and real-time communications are rapidly becoming the default interface for AI-powered tools, moving from experimental demos to production features that millions of users will touch daily.

Cloudflare’s inbound TCP and full-duplex gRPC support doesn’t just add a protocol checkbox; it dissolves the architectural compromise that forced latency-sensitive streaming workloads to bypass the edge entirely.

When a single platform can accept raw sockets, route them through durable objects, execute custom containers, and automatically reconcile protocol mismatches, the old argument that “the edge can’t handle stateful streams” collapses.

For organizations where every millisecond of latency translates directly into user frustration or lost revenue, a platform shift of this magnitude demands that the surrounding stack be equally tuned.

Performance optimization at the edge starts with the right infrastructure, but it extends deep into how sites, APIs, and delivery pipelines are engineered—areas where a partner like specialized speed engineering and managed cloud hosting turn raw capability into measurable business advantage.

Whether you’re planning to deploy real-time gRPC workloads to the edge or simply need every asset served with ruthless efficiency, reach out to Andres to discuss a performance architecture that matches the speed of today’s networks. Learn more about the team behind that approach at Andres SEO Expert.