Cloudflare Workers Now Support Inbound TCP and gRPC, Simplifying Real-Time Apps

Cloudflare Workers Now Support Inbound TCP and gRPC, Simplifying Real-Time Apps

AI is changing how people interact with computers, and voice is becoming an increasingly important part of that shift. Real-time assistants and AI-powered dictation need low-latency communication between clients, models, and supporting services. Many developers use gRPC — a remote procedure call (RPC) framework built on HTTP/2 and TCP — for that infrastructure.

As part of Agents Week, Cloudflare extended Workers in the other direction in August 2026: supporting inbound TCP connections and adding new ways to run gRPC applications on Cloudflare.

connect(socket): Workers accept inbound TCP directly

A new connect(socket) handler in the Workers runtime lets your Worker directly accept an inbound TCP socket provided by Spectrum, Cloudflare's ingress proxy for non-HTTP traffic. Sockets can be passed between Workers, Durable Objects, and Containers, giving you full control over routing and opening the door to full-duplex communication between client and server running any program, in any language, for any TCP-based protocol.

Bidirectional gRPC from Cloudflare Containers

gRPC is a well-established RPC framework used across mobile apps, distributed systems, and, most recently, voice AI applications. Real-time voice AI demands low latency and the ability for both client and server to send messages over a single persistent connection. With the new APIs, you can deploy gRPC servers to Cloudflare in any language with full support for bidirectional streaming between client and server, taking advantage of Cloudflare's 330+ locations to handle requests closer to clients — valuable for low-latency voice and colocated inference.

Workers as gRPC servers and clients — with automatic gRPC-web conversion

Simpler use cases don't need a container. A Worker can serve as a gRPC server or client with automatic conversion between gRPC and gRPC-web. Browsers lack the lower-level HTTP/2 features gRPC requires, and there is no raw TCP socket API in browsers, so Cloudflare translates incoming gRPC to gRPC-web and outgoing gRPC-web to gRPC. Using the open-source @connectrpc/connect package and a protobuf definition, you can write a unary gRPC server in a Worker in just a few lines. Outbound calls to external gRPC servers work the same way.

Typical uses:

• Provide gRPC backends to mobile apps that already speak gRPC, using native libraries like grpc-swift-2 and grpc-kotlin.
• Put a Worker in front of an existing gRPC backend, moving performance-critical work closer to users — just as developers already do with REST APIs and Durable Objects.

A Minimal ConnectRPC Worker Service

A minimal "unary" gRPC service fits in a few dozen lines inside a Worker. Use the types generated from protobuf together with @connectrpc/connect:

// say.proto: service Say { rpc Hello(HelloRequest) returns (HelloReply); }
import { createConnectRouter } from '@connectrpc/connect';
import { Say } from './gen/say_pb';

export default {
  async fetch(req: Request): Promise<Response> {
    const router = createConnectRouter();
    router.service(Say, {
      async hello(req) {
        return { message: `Hello, ${req.name}` };
      },
    });
    return router.handler(req);
  },
};

Nothing changes on the browser side: Cloudflare automatically translates the gRPC-web requests browsers send into gRPC for this Worker. One point worth emphasizing: gRPC serializes with protobuf, and the payload is typically 3-10x smaller than JSON, which is friendlier to mobile bandwidth and battery — a big reason voice AI and mobile apps prefer it.

gRPC vs REST: Trade-offs

If your clients are browsers only and the API is public, REST is usually simpler. When you have a mobile app, dense service-to-service calls, or need low-latency bidirectional streaming, gRPC's advantages are clearer. gRPC-web sits in between, letting browsers enjoy the same interface definition.

Prerequisites and Getting Started

These capabilities are in private beta, so trying them takes three steps:

1. Register a Cloudflare account and enable Workers (the free plan covers the basics);
2. Apply to the gRPC/TCP private beta through official channels;
3. Prepare a protobuf definition and a local dev environment so you can debug locally with wrangler dev.

Reference: Cloudflare blog post https://blog.cloudflare.com/grpc-workers/, gRPC docs https://grpc.io/docs/, ConnectRPC docs https://connectrpc.com/docs/

What's next

These capabilities are in private beta. Cloudflare itself uses Cap'n Proto and its JavaScript-native RPC system, so it wants to work closely with a small set of gRPC developers before turning this on for everyone. Longer term, Cloudflare plans to keep pushing beyond TCP toward UDP-based protocols.

16IDC perspective

For developers building real-time apps, voice tools, or mobile backends, these capabilities mean the edge is no longer just a distribution layer for HTTP requests — it can host real persistent connections and bidirectional streams. To build the fundamentals, start with API integration basics and REST vs GraphQL; for real-time push, see WebSocket real-time communication. More in the Backend Integration category.

Source: https://blog.cloudflare.com/grpc-workers/