Workers Can Now Accept Inbound TCP and Serve gRPC: Cloudflare Closes the HTTP-Only Gap

Since Workers launched in 2017, the platform could only be a server for HTTP traffic. You could open outbound TCP sockets to databases and services, but nothing inbound: no custom protocols, no raw sockets, no gRPC servers. On August 3, as part of Agents Week, Cloudflare announced the closing of that gap. Workers and Containers can now accept inbound TCP connections, and Workers can serve and call gRPC APIs with automatic protocol translation. It is in private beta today, with a signup form on the announcement post.

What shipped#

Three capabilities landed together:

1. connect(socket) handler: a new handler in the Workers runtime that accepts an inbound TCP socket. A Worker can read and write to it directly, pass it to another Worker, or hand it to a Durable Object. Cloudflare routes the raw TCP traffic through Spectrum, its existing ingress proxy for non-HTTP traffic, to the Worker you specify.

2. Full-duplex bidirectional gRPC from Cloudflare Containers: a Worker accepts the socket and forwards it to a gRPC server running in a container, using getTcpPort() on the container API. The announcement shows a Go gRPC echo server and a Python socketserver example that run unmodified. This opens any TCP-based protocol, in any language, to Cloudflare's 330+ location network.

3. gRPC as a first-class Worker protocol: Workers can serve unary and server-streaming gRPC APIs and call external gRPC servers, no container required. The trick is protocol translation: your code uses gRPC-web (browser-compatible gRPC), and Cloudflare converts incoming gRPC to gRPC-web and outgoing gRPC-web to gRPC. Clients using native gRPC libraries like grpc-swift-2 and grpc-kotlin need no changes. The @connectrpc/connect package provides the server and client plumbing.

Cloudflare has been translating gRPC internally since 2020, when it described the approach in its "Road to gRPC" post: convert requests to HTTP/1.1 so messages can be inspected and security features like WAF rules and Bot Management can apply.

Why it matters to developers#

The release targets one workload above all: real-time voice AI. Voice interfaces need low-latency, persistent, bidirectional connections between client, model, and supporting services. gRPC over a single TCP connection is a standard way to build that, and Cloudflare's pitch is that you can now run that stack on its edge network instead of on your own infrastructure or a cloud VM fleet.

Three developer-facing takeaways:

• Workers stop being HTTP-only. Any TCP-based protocol can now terminate on Workers. The connect() handler pattern is a small, readable addition to the runtime, and the Durable Object integration means connection state has an obvious home. The example where a Worker pipes an inbound socket to a Durable Object, which pipes it to a container port, is the platform's full stack in 20 lines.

• gRPC backends for mobile apps are now deployable without a container. If your mobile client already speaks gRPC for payload size and generated clients, a Worker can now be the backend, as long as your service shape fits unary or server-streaming calls. Bidirectional streaming still needs the container path.

• Edge proximity finally applies to gRPC. The strongest use case is colocated inference: serving a gRPC API from locations near the client, where the model call stays close to the user. Combined with Containers for the parts that need a real userland, this is a meaningful option for latency-sensitive AI products.

The honest constraints#

Private beta means the API shape could change. The announcement is explicit that Cloudflare itself prefers Cap'n Proto and its JavaScript-native RPC system over gRPC, and that it wants to work with a smaller set of gRPC users before turning it on for everyone. So treat the code examples as direction, not a stable contract, until it goes public.

There is also the question of what inbound TCP on Workers means for abuse surface. Spectrum has always been the controlled ingress for non-HTTP traffic; adding a Worker in front of raw sockets keeps that control, and Cloudflare's WAF and Bot Management story continues to apply to translated gRPC traffic.

How it fits with adjacent tools#

This is the third day of Cloudflare's Agents Week, and the theme is consistent: the platform is building the raw material for agent infrastructure, not just agent SDKs. Inbound TCP and gRPC fit the same thesis as @cloudflare/computer (agents pick between isolates and containers) and the agent cloud positioning from the week's opening post. For real-time voice workloads, this post is the transport story behind the @cloudflare/voice channel in the Agents SDK.

The pattern is also familiar from other platforms. Vercel has been building durable execution and sandboxes for the same workloads, and Durable Objects on Workers have long been the closest thing to WebSocket state at the edge. Inbound TCP extends that to any protocol.

Continue Reading#

• @cloudflare/computer: an Agent Runtime That Treats a Container as a Tool, Not a Home
• Cloudflare Temporary Accounts for AI Agents
• OpenAI Realtime Voice API: Building Real-Time Speech Agents
• Vercel's Durable Execution Model for Background Agents
• Agent Sandbox Architecture: Isolates, Containers, and MicroVMs

Sources#

• Cloudflare Blog: Cloudflare Workers and Containers now support inbound TCP connections and gRPC (fetched August 3, 2026)
• Cloudflare: The Road to gRPC (2020)
• gRPC web documentation
• Cloudflare Spectrum documentation