Cloudflare Workers soporta TCP y gRPC: qué cambió
Actualizado el 05/08/2026: Cloudflare confirmó que el soporte de gRPC ya está disponible en Workers, con la posibilidad de rutear, transformar y servir servicios gRPC de forma nativa en el edge, sin sostener una capa de proxy dedicada. La novedad viene acompañada de documentación oficial de runtime API para gRPC.
En pocas palabras: Cloudflare habilitó que Workers y Containers acepten conexiones TCP entrantes y gRPC nativo, incluyendo streaming server-side y full-duplex, usando el handler connect(socket). Ahora suma soporte de gRPC listo para rutear, transformar y servir servicios sin proxy dedicado, con documentación de runtime API publicada. Corre en más de 330 ubicaciones globales.
Cloudflare anunció que Workers y Containers aceptan conexiones TCP entrantes y soportan gRPC de forma nativa. La novedad más grande: por primera vez podés recibir tráfico TCP crudo en un Worker —no solo HTTP— y servir APIs gRPC unarias, server-streaming desde Workers, o full-duplex desde Containers, todo corriendo en las más de 330 ubicaciones de la red. Y ahora la plataforma da un paso más: rutear, transformar y servir gRPC directamente, sin mantener un proxy aparte.
El soporte de gRPC en Cloudflare Workers permite aceptar conexiones TCP entrantes mediante el handler connect(socket) y servir APIs gRPC directamente desde el edge, sin proxy intermedio ni traducción manual de protocolos. Cloudflare convierte automáticamente entre gRPC nativo y gRPC-web, habilitando clientes móviles nativos sin que toques una línea del lado del cliente. La documentación de runtime API ya está publicada.
En 30 segundos
- gRPC ya está disponible en Workers: podés rutear, transformar y servir servicios gRPC de forma nativa en el edge, con documentación oficial de runtime API publicada.
- Se elimina el proxy dedicado: no necesitás mantener una capa tipo Envoy adelante para traducir o enrutar gRPC. El Worker lo hace en línea.
- Workers acepta conexiones TCP entrantes mediante el handler
connect(socket), usando Spectrum como proxy de ingreso para tráfico no HTTP. - gRPC unario y server-streaming corre en Workers sin contenedores; para full-duplex y bidireccional necesitás Cloudflare Containers.
- Traducción automática gRPC ↔ gRPC-web: escribís en gRPC-web y Cloudflare se encarga de la conversión con clientes nativos.
Cloudflare es una plataforma de servicios de red desarrollada por Cloudflare Inc., que proporciona CDN, seguridad y aceleración de sitios web mediante una infraestructura global de servidores.
Cloudflare es una empresa de servicios de red y seguridad web que provee CDN, protección contra ataques DDoS y una plataforma de computación edge para aplicaciones, con presencia en más de 330 ubicaciones.
¿Qué agrega el soporte de gRPC ahora disponible en Cloudflare Workers?
La novedad concreta es que gRPC pasó de ser un experimento en beta a una capacidad documentada: podés rutear, transformar y servir servicios gRPC nativamente en Workers, sin sostener infraestructura de proxy dedicada. Ese último punto es el cambio de fondo. Hasta ahora, llevar gRPC al edge implicaba poner un proxy adelante —un Envoy, un sidecar, algo que hiciera la traducción y el ruteo.
Eso desaparece. El Worker deja de ser solo un endpoint HTTP con gRPC pegado con cinta: ahora enruta las llamadas gRPC según el método o el servicio, transforma entre gRPC nativo y gRPC-web en línea, y sirve la respuesta sin salto extra. La diferencia con la versión que cubrimos antes es de madurez operativa, no de un feature suelto. Antes tenías el mecanismo (connect(socket)); ahora tenés el patrón completo respaldado por documentación de runtime API.
¿Por qué importa el detalle del “sin proxy dedicado”? Porque un proxy gRPC es un componente que hay que desplegar, escalar, parchar y monitorear. Es un punto de fallo más y una línea de costo fija. Moverlo al runtime de Workers lo vuelve parte de la misma unidad de ejecución que ya corre tu lógica. Habría que ver cómo se comporta bajo carga real y con esquemas grandes, pero la promesa de arquitectura es clara: menos piezas móviles entre el cliente y tu servicio. Sobre el protocolo en sí, la referencia canónica sigue siendo grpc.io.
Antes vs ahora: qué cambió respecto a la primera beta de gRPC en Workers
El salto principal es de “podés hacerlo si armás la plomería” a “está documentado como capacidad de plataforma”. La tabla resume los ejes donde se nota la diferencia entre la versión inicial que cubrimos y el estado actual.
| Aspecto | Beta inicial (TCP entrante) | gRPC disponible (ahora) |
|---|---|---|
| Ruteo de servicios gRPC | A mano, en tu código | Nativo en el Worker |
| Proxy dedicado (tipo Envoy) | Recomendable como capa aparte | Ya no hace falta |
| Transformación gRPC ↔ gRPC-web | Automática | Automática, documentada |
| Documentación de runtime API | Anuncio en el blog | Página oficial de runtime API |
| Modelo mental | Mecanismo (connect(socket)) | Patrón completo respaldado |
Lo que no cambió: el reparto de tareas entre Workers y Containers. Los Workers siguen sirviendo unario y server-streaming; el full-duplex sigue viviendo en Containers con Durable Objects. Tampoco cambió que trabajás contra gRPC-web y la plataforma traduce. Es decir, quien ya prototipó con la beta no tiene que reescribir nada: gana ruteo nativo y documentación, no una API distinta. Complementá con gestión segura de credenciales en Workers.
¿Qué significa que Workers ahora acepten conexiones TCP entrantes?
Desde 2017, un Worker solo podía responder tráfico HTTP. Si querías manejar otra cosa, tenías que poner algo adelante que tradujera. Eso cambió.
Ahora el runtime de Workers incluye un handler connect(socket) que recibe un socket TCP crudo —provisto por Spectrum, el proxy de ingreso para tráfico no HTTP de Cloudflare— y te deja leer y escribir con las APIs estándar de readable y writable. Nada de WebSockets disfrazados ni tunnelling raro. TCP real, del que usás para gRPC, bases de datos, o lo que se te ocurra.
El ejemplo mínimo del anuncio es directo: abrís el socket, escribís un mensaje con writer.write(), y cerrás. Veinte líneas y ya tenés un servidor TCP corriendo en el edge. Más contexto en proteger tus credenciales con Secrets Manager.
¿Cómo funciona la traducción automática entre gRPC y gRPC-web?
Vos escribís tu código usando gRPC-web —que es lo que los navegadores entienden— y Cloudflare convierte automáticamente las requests entrantes de gRPC nativo a gRPC-web, y las salientes de gRPC-web a gRPC nativo. Sin polyfills, sin proxies extra.
Esto significa que si ya tenés clientes móviles con gRPC nativo, no necesitás cambiarlos. Siguen hablando gRPC como siempre. Cloudflare ya venía trabajando con gRPC-web internamente, así que la traducción corre sobre una capa probada.
¿Y cuando necesitás streaming bidireccional? Ahí el asunto se complica: gRPC-web no soporta full-duplex de forma nativa. Pero Cloudflare lo resolvió por otro camino. Tema relacionado: arquitectura DNS moderna para servicios distribuidos.
¿Qué tipos de gRPC se pueden servir desde Workers y desde Containers?
No todo corre en el mismo lugar. Depende de qué tan pesado sea el handshake.
Workers pueden servir APIs gRPC unarias (request-response clásico) y server-streaming (el servidor manda un chorro de datos y el cliente escucha). También pueden actuar como cliente y llamar servidores gRPC externos. Para el 80% de los casos de uso, esto alcanza.
Cloudflare Containers entran cuando necesitás full-duplex y bidireccional. El flujo es: un Worker recibe el socket TCP de Spectrum, lo pasa a un Durable Object, y ese Durable Object lo reenvía al servidor gRPC que corre dentro de un contenedor. El ejemplo que mostraron es un echo server. Cubrimos el tema de resiliencia en detalle en cómo evitar caídas de DNS.
La decisión de separar Workers de Containers para full-duplex no es caprichosa: un Worker está diseñado para ejecuciones cortas y stateless. Mantener una conexión persistente bidireccional requiere estado, y ahí los Durable Objects brillan porque existen justamente para manejar estado con afinidad de ubicación.
| Tipo de gRPC | ¿Corre en Workers? | ¿Corre en Containers? | Caso de uso típico |
|---|---|---|---|
| Unario | Sí | Sí | APIs CRUD, consultas puntuales |
| Server-streaming | Sí | Sí | Descarga de reportes, feeds en tiempo real |
| Client-streaming | No directamente | Sí | Upload de datos por chunks |
| Bidireccional / Full-duplex | No | Sí | Asistentes de voz, streaming de audio |
¿Cómo se usa connect(socket) con Durable Objects?
Para exponer un servidor gRPC que corre en un contenedor, el patrón que propone Cloudflare, según el anuncio oficial, es de unas 20 líneas:
- El Worker recibe el socket mediante el handler
connect(socket). - Se lo pasa a un Durable Object, porque la conexión tiene estado y querés que viva en un solo lugar.
- El Durable Object conecta el socket al puerto del contenedor donde corre tu servidor gRPC.
- El tráfico fluye de punta a punta, sin sticky sessions armadas a mano.
El estado de la conexión —quién está conectado, en qué punto de la sesión va, si hay que reintentar algo— encuentra un hogar natural en Durable Objects. No tenés que armar Redis ni manejar afinidad a mano: la ubicación te la da Cloudflare.
¿Cómo implementar un servidor gRPC unario en Workers?
Si ya trabajaste con Protocol Buffers, la curva es plana. Definís el servicio a partir de un archivo .proto y lo exponés en un Worker con muy poco código.
El mismo código funciona como cliente para hacer requests salientes a servidores gRPC externos. O sea que el Worker puede ser servidor, cliente, o ambas cosas al mismo tiempo. Si venís de construir microservicios con gRPC en Kubernetes, el modelo mental se traslada casi idéntico al edge. Sobre eso hablamos en rendimiento del edge computing vs alternativas.
Subís el Worker, definís el servicio con el mismo .proto que usás del lado del cliente, y Cloudflare se encarga de la traducción gRPC-web ↔ gRPC. Los clientes móviles no notan la diferencia. Tema relacionado: el benchmark de contenedores frente a MicroVMs.
¿Qué aplicaciones se benefician de gRPC en el edge de Cloudflare?
El anuncio menciona tres casos que explican por qué movieron ficha ahora:
- Backends gRPC para apps móviles: si tu app ya usa gRPC nativo, movés el backend al edge sin reescribir el protocolo. Menos latencia, misma API.
- Inferencia de IA co-ubicada: correr modelos pequeños en Workers y servir las predicciones vía gRPC, con cliente y modelo separados por single-digit de latencia gracias a las 330+ ubicaciones.
- Asistentes de voz en tiempo real y dictado por IA: necesitan full-duplex, baja latencia y estado de sesión. Containers + Durable Objects + gRPC bidireccional encaja justo.
Si tenés infraestructura hosteada en Argentina, por ejemplo en donweb.com, y querés complementarla con una capa de edge para reducir latencia en APIs gRPC que consumen clientes móviles en toda Latinoamérica, este enfoque híbrido —contenedores en el edge para lo crítico, infraestructura tradicional para el resto— se vuelve viable sin armar un enredo de proxies.
Qué significa para empresas y equipos en Latinoamérica
Para un equipo latinoamericano, el beneficio directo es operativo: podés servir gRPC en el edge sin sostener un proxy dedicado, que es una pieza menos para desplegar y monitorear con equipos chicos. Ese ahorro de complejidad pesa más acá, donde no siempre sobra gente de plataforma.
El tema es que la red de 330+ ubicaciones acerca la lógica al usuario final, algo relevante para apps móviles con tráfico distribuido entre Argentina, México, Colombia y el resto de la región. Una API gRPC que antes viajaba a un datacenter único ahora puede resolverse más cerca. Ahora bien, conviene medir con tu propio tráfico: la ganancia de latencia depende de dónde estén tus usuarios y tu servicio de origen. Un esquema híbrido —hosting tradicional en Argentina para lo pesado, edge para lo latency-sensitive— es lo más sensato hasta tener números propios.
Qué está confirmado y qué todavía no
- Confirmado: gRPC disponible en Workers para rutear, transformar y servir servicios sin proxy dedicado, con documentación de runtime API publicada. Workers acepta TCP entrante con
connect(socket)vía Spectrum. gRPC unario y server-streaming desde Workers. Full-duplex y bidireccional desde Containers con Durable Objects. Traducción gRPC ↔ gRPC-web automática. - No confirmado: precios específicos del tráfico TCP/gRPC en producción. Si client-streaming llegará a Workers sin contenedor. Límites de conexiones concurrentes por Worker para TCP. Números públicos de rendimiento comparado bajo carga real.
Errores comunes al meter gRPC en Workers
Estos tropiezos aparecen una y otra vez en proyectos que intentan llevar gRPC al edge. Ojo con:
Asumir que full-duplex anda en Workers. No anda. Vas a perder horas debugueando timeouts raros. Si necesitás bidireccional, arrancá directo con Containers. El Worker solo sirve de puente entre Spectrum y el contenedor.
Olvidar que el .proto tiene que coincidir en ambos lados. gRPC no es REST: si cambiás un campo del mensaje sin actualizar la definición compartida, cliente y servidor dejan de entenderse sin que salte un error evidente. Usá un repositorio centralizado para los .proto o un registry como Buf. En almacenamiento de objetos sin costos de egreso profundizamos sobre esto.
Usar gRPC pensando que mágicamente es más rápido que HTTP/2 con JSON. Para payloads chicos y poca frecuencia, la diferencia es marginal. gRPC brilla con streaming, alta frecuencia de mensajes y tipado fuerte. Si tu API es un CRUD de 3 endpoints, probablemente no lo necesitás. Sobre eso hablamos en la comparativa de R2 frente a S3.
Preguntas Frecuentes
¿gRPC ya está disponible en Cloudflare Workers?
Sí, Cloudflare confirmó que el soporte de gRPC está disponible en Workers. Permite rutear, transformar y servir servicios gRPC de forma nativa en el edge sin sostener un proxy dedicado, y ya cuenta con documentación oficial de runtime API para su implementación.
¿Necesito un proxy dedicado para servir gRPC en el edge de Cloudflare?
No. El punto central de la novedad es que ya no hace falta mantener una capa de proxy dedicada tipo Envoy adelante. El Worker rutea, transforma entre gRPC nativo y gRPC-web, y sirve la respuesta en línea, lo que reduce piezas móviles, costos fijos y un punto de fallo.
¿Cloudflare Workers ahora soporta conexiones TCP entrantes?
Sí. El handler connect(socket) permite a un Worker aceptar sockets TCP crudos que llegan a través de Spectrum, el proxy de ingreso para tráfico no HTTP de Cloudflare. Sobre ese socket TCP se apoya el soporte de gRPC nativo.
¿Necesito un contenedor para usar gRPC bidireccional en Cloudflare?
Sí. Workers solo soporta gRPC unario y server-streaming. Para full-duplex y bidireccional el flujo requiere Cloudflare Containers: el Worker recibe el socket TCP y lo reenvía al servidor gRPC del contenedor, usando Durable Objects para manejar el estado de la conexión.
¿Qué es gRPC-web y cómo lo usa Cloudflare?
gRPC-web es una variante del protocolo gRPC compatible con navegadores. Cloudflare lo usa como capa intermedia: programás contra gRPC-web y la plataforma traduce las requests entrantes de gRPC nativo a gRPC-web, y las salientes en sentido inverso, sin adaptaciones del lado del cliente.
Conclusión
gRPC dejó de ser un experimento en Workers para volverse una capacidad documentada: rutear, transformar y servir servicios gRPC en el edge, sin un proxy dedicado adelante. El cambio no es una API nueva, es madurez operativa. Quien ya prototipó con la beta gana ruteo nativo y documentación de runtime API, sin reescribir nada.
Por qué importa: cada componente que sacás del camino entre el cliente y tu servicio es menos costo, menos latencia y un punto de fallo menos. Para backends mobile-first, inferencia de IA co-ubicada y asistentes de voz, correr gRPC directo en la red de Cloudflare cierra un hueco que antes obligaba a armar infraestructura de proxy propia. Lo que conviene seguir de acá en adelante: el pricing del tráfico TCP/gRPC en producción, los límites de conexiones concurrentes y si client-streaming llega a Workers sin contenedor. Si ya usás gRPC en el backend, es buen momento para medir con tu propio tráfico.
