Cloudflare Python Workers reach GA as performance and safety questions surface

Python now joins Cloudflare’s serverless platform, but maintainers and rivals are probing security and startup lag.

Cloudflare has moved Python Workers to general availability on its Developer Platform, adding bindings to services like Workers AI, R2, D1, Hyperdrive and Queues, plus support for frameworks such as FastAPI, Django and Flask. To make this viable, Cloudflare drove PEP 783 for the PyEmscripten platform so package authors can cross‑compile C/C++/Rust extensions to WebAssembly themselves, implemented a syscall bridge so socket‑based drivers can run over the Workers connect API, and contributed upstream changes so HTTP clients like requests and httpx use the JavaScript fetch API under WebAssembly. The launch has triggered debate over funding and maintenance: urllib3’s maintainer notes that Cloudflare paid a contributor rather than core maintainers for Pyodide/Emscripten support, that urllib3’s Emscripten backend is still experimental and not covered by its security policy, and that at least one CVE has already arisen from differences in browser networking semantics. Performance and platform coupling are also under scrutiny, with Wasmer founder Syrus Akbary citing benchmarks where a minimal Python app starts in about 60ms on Wasmer Edge versus roughly 900ms on Cloudflare Workers, asking Cloudflare to share current cold‑start percentiles, and questioning the tight link between supported Python versions and the embedded Pyodide/runtime stack. Cloudflare engineers respond that memory snapshots and sharding have already improved cold starts, that compatibility flags currently expose Python 3.12–3.14 with corresponding Pyodide versions, and that using the JavaScript event loop ensures Python coroutines remain lazy while integrating cleanly with the runtime’s I/O model, even as some commenters worry about additional memory overhead from the Python stack.