Connecting an internal inventory system with an external logistics partner's system: as the requirements are fleshed out, the partner requests to receive traffic over gRPC. At this point, any edge architecture previously under consideration is dropped from the candidate list.
The reason is simple: since its debut in 2017, Cloudflare Workers could only receive HTTP as a server. While it could initiate outgoing connections to databases and external services, it could not act as the receiving side for non-HTTP connections. The moment gRPC or a custom TCP protocol entered the requirements, the natural choice was to opt for virtual machines or container services.
During Agents Week in August 2026, this assumption shifted.
Accepting TCP with the connect handler
Cloudflare announced that Workers and Containers can now accept inbound TCP connections. Routed via Spectrum, they are handled through a new connect(socket) handler. The core of this change is that Workers can now act as servers for protocols other than HTTP.
gRPC was introduced as the first protocol running on top of this. Support differs between Containers and Workers.
| Execution environment | gRPC support scope |
|---|---|
| Containers | Full-duplex gRPC in any language |
| Workers | Unary and server streaming (via automatic gRPC-web conversion) |
Because the Workers side automatically converts between gRPC and gRPC-web, it enables architectures where you can insert it in between without modifying existing clients and servers. This shines not in "rebuilding from scratch" scenarios, but in "placing in front of what already exists" use cases.
Currently, everything is in private beta. Cloudflare states that it will next expand to UDP-based protocols.
What types of projects benefit?
Since that might sound abstract, let us outline them in terms of requirements.
First is when you want to make existing gRPC services accessible globally. You will be able to deploy gRPC servers across a network of over 330 locations. For internal systems where connection latency from international offices is a challenge, this delivers straightforward benefits.
Second is when external integrations cannot be migrated to HTTP. The partner's system is strictly locked into gRPC and cannot be switched to REST just to accommodate your needs. Projects that had to abandon edge architectures purely for this reason fall into this category.
Third is when receiving persistent connections from equipment or devices. This requires inbound TCP reception itself. However, since support is currently limited to gRPC, architectures that require routing custom protocols must still wait.
Do not include private beta features in project requirements
This is the most critical point in practice: do not base contracted project prerequisites on private beta features.
There are three reasons. Release timing is not guaranteed. Applying does not ensure you will receive access, making it impossible to fix a development start date. Specifications may change. Both handler signatures and constraints could shift before general availability. They lack official support. When incidents occur, escalation channels remain under beta terms.
Testing them hands-on is valuable. Keeping them as candidates during technical selection is perfectly fine. However, the moment you draw up a schedule contingent on this feature arriving, that project loses control. You must establish an escape hatch before signing the contract in case general availability slips by six months.
How to build an escape hatch
Practically speaking, ensuring that the layer receiving gRPC remains swappable is the most reliable approach.
- Decouple the protocol translation layer from business logic. By keeping the component that receives gRPC and converts it into internal calls thin and independent, you can later swap out where only that layer is hosted.
- Make a non-edge architecture your primary plan. Run it on container services or virtual machines first, treating an edge migration as a subsequent improvement. Building something that works first and pursuing speed later is an order of operations that avoids delivery failures.
- Assess the degree of vendor lock-in beforehand. The
connect(socket)handler uses syntax proprietary to Cloudflare. Because selecting infrastructure is also selecting migration feasibility, decide upfront how heavily to lean on proprietary APIs.
If HTTP is sufficient, that remains your best choice
Finally, let us also verify the opposite perspective: projects where gRPC is a genuine requirement are actually not that common.
For integrations between internal systems where traffic is moderate and real-time demands are not extreme, REST or an RPC library capable of sharing types is more than sufficient. Architectures that simply place an HTTP API on Workers remain effective today, and the pool of developers capable of handling them is vastly larger.
Valid reasons to choose gRPC arise when it is dictated by partner constraints, or when bidirectional streaming is an explicit business requirement itself. Choosing it simply because "it seems fast" will leave you stranded when searching for someone who can maintain it.
What to do next
First, check whether any projects currently under review require non-HTTP communication. If none do, this update will not affect your immediate decisions. Simply knowing that an extra option will be available six months down the road is plenty.
If it is in your requirements, determine whether that requirement is an unalterable constraint from the other party or merely your own preference. If it is a preference, sticking with HTTP will be faster and cheaper. If it is a fixed constraint, wait for edge placement to reach general availability and plan an initial rollout using a functional, proven architecture first.
GleamHub provides consultation on development, AI, and automation covering system-to-system integration design, cloud migration of existing systems, and infrastructure architecture selection. Because the optimal setup varies based on integration constraints and required response performance, please consult with us individually. Reach out via our contact page.
