Cloudflare lleva Python Workers a GA: Python nativo en el edge

Cloudflare lleva Python Workers a disponibilidad general: ya puedes correr Python nativo en el edge

Cloudflare anunció que Python Workers ya está generally available (GA) en su plataforma de desarrollo. Tras dos años en beta, Python se convierte en lenguaje de primera clase en el runtime de Cloudflare Workers, con soporte completo de bindings, sockets TCP, frameworks web y librerías de IA, todo ejecutándose sobre la red global de la compañía.

El anuncio, publicado en el blog oficial de la compañía, detalla un cambio de fondo: ya no hace falta código glue en JavaScript para hablar con Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues o Workflows. Ahora un simple self.env.QUEUE.send({"key": "value"}) funciona en Python puro, sin conversiones a objetos JS. Para un founder hispanohablante esto significa algo concreto: lo que aprendiste en cualquier tutorial de FastAPI o Django sirve, sin reescribir nada, en una plataforma que escala automáticamente hasta 330 ciudades en el mundo.

Qué cambia con la versión GA

Durante la beta, los developers que querían usar Cloudflare tenían que pelearse con la barrera entre Python y JavaScript. El ejemplo clásico: enviar un diccionario a una Queue exigía from pyodide.ffi import to_js y to_js({"key": "value"}, dict_converter=js.Object.fromEntries). Cualquier IA generativa que escribiera código por ti fallaba en ese punto, y era una fuente constante de bugs.

La versión GA elimina esa fricción en tres frentes:

• Bindings nativos de Python para toda la plataforma: Workers AI, R2, D1, Hyperdrive, Queues, Workflows y Durable Objects se invocan directamente desde Python sin código de conversión.
• Soporte nativo de FastAPI, Django y Flask mediante los conectores workers.asgi y workers.wsgi, que traducen la petición entrante del runtime JavaScript a las interfaces estándar WSGI/ASGI.
• Sockets TCP reales dentro del sandbox de WebAssembly, lo que desbloquea drivers de PostgreSQL y MySQL (asyncpg, aiomysql), clientes HTTP (httpx, requests) y librerías de IA como openai, langchain y mcp.

El truco técnico detrás de los sockets fue implementar las syscalls POSIX de red sobre la connect API de Workers. Cuando asyncpg o aiomysql piden abrir un socket, la syscall se traduce a la llamada equivalente del runtime JavaScript. El driver no sabe que está en WebAssembly, simplemente funciona.

Un estándar abierto para Python sobre WebAssembly

Quizás la pieza más estratégica del anuncio no es técnica, sino de ecosistema. Cloudflare impulsó y logró que se aprobara la PEP 783, que define PyEmscripten, una plataforma estándar para correr Python en runtimes de navegador. Esto permite a los mantenedores de paquetes publicar wheels compatibles con WebAssembly que funcionan en Pyodide y, por extensión, en Python Workers.

La compañía también estabilizó la toolchain de build de Pyodide, la puso accesible a mantenedores e integró soporte para PyEmscripten en cibuildwheel. El objetivo declarado: que cada paquete Python del ecosistema tenga, eventualmente, una wheel que funcione en WebAssembly sin parches.

Si tu startup depende de una librería Python específica, este es el dato clave: ya no dependes de que Cloudflare la compile a mano. Cualquier autor de paquete puede publicar el soporte y tu Workers lo reconoce automáticamente.

Lo que puedes construir hoy mismo

Cloudflare publicó un repositorio de ejemplos python-workers-examples con patrones listos para producción. Cuatro casos digno de mención:

• Orquestación asíncrona de IA: un generador imagen-a-imagen que recibe requests, los encola en Cloudflare Queues y orquesta la inferencia con Workers AI y Workflows, guardando el resultado en R2. Todo en Python puro.
• Stream processing en tiempo real con Bluesky Jetstream: un Worker Python mantiene una conexión WebSocket al firehose de ATProto respaldado por un Durable Object, sin servidor dedicado.
• Servidor MCP (Model Context Protocol): deploy de un servidor MCP con el paquete oficial de Python para dar a tus asistentes IA acceso a datos en el edge.
• Sistema RAG con Vectorize: pipeline completo de retrieval-augmented generation usando Workers AI y la base vectorial de Cloudflare.

Además, la documentación de Cloudflare ahora muestra ejemplos en Python casi donde antes solo había TypeScript, con un toggle entre JavaScript, TypeScript y Python en cada snippet.

¿Qué significa esto para tu startup?

Tres implicancias prácticas si estás eligiendo dónde correr tus APIs y agentes de IA:

• Migración cero de código si ya usas FastAPI o Django. Tu archivo main.py se importa tal cual en Python Workers; solo añades un Default = asgi.entrypoint(app). Si hoy gastas en Uvicorn + Gunicorn detrás de un load balancer, esa capa desaparece.
• Acceso a GPU sin gestionar infraestructura. Workers AI corre inferencia en GPUs de la red de Cloudflare, y desde Python Workers lo invocas con env.AI.run("@cf/openai/gpt-oss-120b", ...). Para founders en LATAM, esto resuelve el problema histórico de no tener acceso económico a GPUs.
• Cold start sub-50ms en la red global, según las pruebas que Cloudflare viene publicando desde 2024. Frente a AWS Lambda (cold starts de cientos de milisegundos en Python), Workers sigue siendo la opción dominante para APIs de baja latencia.

El contexto de fondo importa: según un análisis de Yahoo Finance sobre los resultados del Q2 2026, Cloudflare creció 36% interanual a US$696,1 millones y añadió un récord de 986 clientes grandes. Su CFO, Thomas Seifert, confirmó en la conferencia de Goldman Sachs que Workers sigue siendo el "act" (vertical de negocio) de mayor crecimiento dentro de la compañía, por encima incluso de SASE (Zero Trust). Python Workers GA llega, justamente, cuando la división de developers es la que más tracción muestra dentro del negocio.

Acciones concretas que puedes tomar esta semana

1. Audita tu stack Python y mira qué se mueve a Workers sin reescritura. Si tienes una API en FastAPI, Django o Flask, prueba el conector workers.asgi o workers.wsgi en un Worker nuevo. El cambio es de cinco líneas: importar asgi, definir el WorkerEntrypoint y apuntar al app existente. Lo que tardes en provisionar tu cuenta vale más que cualquier POC teórica.
2. Identifica un agente de IA que hoy corra en un servidor con GPU dedicada. Moviendo ese agente a Python Workers + Workers AI, eliminas el costo fijo de la GPU y pagas solo por inferencia. Empieza con un agente de bajo tráfico para validar latencia y costo antes de migrar el resto.
3. Revisa tu capa de PostgreSQL o MySQL. Si tu app Python se conecta a una base relacional en otra región, el binding Hyperdrive con asyncpg o aiomysql puede cortar la latencia entre tu Worker y la base, porque Hyperdrive mantiene conexiones pool cerca del edge. Es el caso de uso donde el ROI es más visible.

Lo que viene después de GA

El propio anuncio de Cloudflare es explícito: GA es el inicio, no el final. La compañía adelantó tres frentes abiertos: mejorar el rendimiento y la eficiencia de memoria de Python Workers, ampliar el catálogo de paquetes soportados y seguir colaborando con mantenedores para que más wheels se compilen para PyEmscripten.

Para una startup que evalúa dónde correr su backend Python en 2026, la señal es clara: la barrera entre "Python local en mi laptop" y "Python distribuido en 330 ciudades del mundo" dejó de existir en términos de código. La decisión ahora es de costos, observabilidad y compliance, no de portabilidad.

Fuentes

• Python Workers are now generally available (fuente original)
• Cloudflare's Q2 beat: Workers is the fastest-growing act