Cloudflare Python Workers: GA tras dos años de preview

Cloudflare Python Workers llegan a GA: Python ya es idioma nativo en Workers

Cloudflare puso en disponibilidad general a Python Workers el 21 de septiembre de 2026, después de un período de preview de dos años. El anuncio lo acreditan Gyeongjae Choi, Dominik Picheta y Hood Chatham, dos de los cuales son mantenedores principales de Pyodide. El detalle clave de la arquitectura — que Simon Willison rescata en su blog — es que Cloudflare corre Python compilado a WebAssembly mediante Pyodide dentro del runtime workerd basado en V8.

En términos prácticos, el cambio significa que Python deja de ser un experimento en la plataforma y pasa a ser un «idioma de primera clase, completamente soportado», al mismo nivel que TypeScript.

Qué cambia con la disponibilidad general

El movimiento no es solo declarativo. Según el anuncio de Cloudflare recogido por TechnoBezz, la GA trae consigo:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Acceso nativo a los bindings de la plataforma: las aplicaciones en Python ahora se conectan directamente a Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues y Workflows, sin tener que traducir manualmente objetos Python a TypeScript en el límite RPC. Una operación que antes requería glue code con pyodide.ffi ahora se escribe como un diccionario Python normal.
Soporte para frameworks web: FastAPI, Django y Flask corren dentro de Python Workers mediante conectores incluidos en la plataforma. Los paquetes workers.asgi (para frameworks asíncronos como FastAPI) y workers.wsgi (para sincrónicos como Django) traducen las requests entrantes a las estructuras WSGI/ASGI que esperan las apps Python. Cloudflare afirma que cualquier framework construido sobre esas dos interfaces funciona, no solo los tres nombrados.
Sockets TCP funcionales: Python Workers antes no podían abrir sockets TCP, lo que bloqueaba a drivers como aiomysql y asyncpg para conectarse a PostgreSQL o MySQL. Cloudflare implementó syscalls de socket sobre la API de connect de Workers, y esa misma pieza es la que habilita la integración con Hyperdrive.

El balance de carga y el escalado los maneja la propia plataforma, en lugar de un servidor tradicional como Uvicorn o Gunicorn.

Las limitaciones que todavía pesan

Hay un precio a pagar por correr Python sobre WebAssembly:

Sin multiprocessing ni threading funcionales en la VM WASM, según la documentación oficial de Cloudflare.
Paquetes con extensiones nativas en C, C++ o Rust tienen que cross-compilarse a WebAssembly. Antes Cloudflare tenía que compilar y alojar esos paquetes por su cuenta, lo que limitaba qué podían usar los desarrolladores. La solución de fondo que propone la empresa es PEP 783 («PyEmscripten»), un estándar para correr Python en runtimes de navegador que fue aceptado tras más de un año de discusión, según TechnoBezz.
El entorno local pesa: pywrangler (empaquetado en PyPI como workers-py) descarga un binario workerd de 123 MB que corre una simulación completa del stack, incluyendo Pyodide sobre V8. En macOS arm64 termina en node_modules/@cloudflare/workerd-darwin-arm64/bin/workerd.

Comparables: el espacio serverless Python en 2026

Cloudflare Workers no compite solo. En el segmento de serverless Python los referentes más mencionados son AWS Lambda, Google Cloud Functions y, en el terreno edge, Vercel Functions con soporte Python y Fastly Compute. La diferencia de Cloudflare es la capa de aislamiento basada en V8 isolates en lugar de contenedores o microVMs, lo que permite arranque casi instantáneo y menor consumo de memoria — patrón que la propia Cloudflare describe en su blog.

Lambda, en cambio, sigue basándose en el modelo de microVM Firecracker, con arranques en el rango de cientos de milisegundos a segundos para Python en frío.

Qué significa esto para tu startup

Si tu stack ya es Python y vienes evitando Workers porque solo soportaba TypeScript, la barrera desapareció.

Acciones concretas para founders y equipos:

Evalúa portar tu API FastAPI o tus jobs de Django a Python Workers si necesitas latencia baja en el edge y ya pagas el costo de mantener un contenedor. La promesa es eliminar Uvicorn/Gunicorn del medio y delegar el escalado en la plataforma. Como primer paso: toma un endpoint pequeño de tu API, empaquétalo en workers.asgi, y mide cold start contra tu setup actual.
Construye pipelines agentic sobre Workers AI + Python: la combinación de Workers AI con Python nativo baja la fricción para escribir herramientas en Python y ejecutarlas en el mismo runtime, sin doble lenguaje. Cuidado con el límite real: paquetes con extensiones nativas siguen pidiendo cross-compile a WebAssembly — revisa las notas de Pyodide y PEP 783 antes de elegir dependencias pesadas como NumPy o criptografía.
Audita drivers de base de datos antes de migrar: si tu capa de datos depende de asyncpg, aiomysql o un driver C nativo, valida primero en pywrangler local. Los sockets TCP ya funcionan, pero los detalles del binding con Hyperdrive viven en la documentación aparte y el anuncio de GA no enumera qué drivers están soportados hoy.

El lanzamiento llega días después de que Cloudflare introdujera controles de acceso más granulares que dejan a un teammate o un agente con permiso de tocar un solo Worker en lugar de la cuenta entera. Leído junto a la GA de Python, pinta el mismo público objetivo: equipos que están poniendo cada vez más código generado por agentes sobre la Developer Platform, donde el blast radius de un permiso mal configurado o una conversión de tipos que falla importa.