Cloudflare brings Python Workers to general availability, but cold start still divides the community

Cloudflare announced the general availability (GA) of the Python runtime for Workers, two years after the first preview, according to reporting from InfoQ. Python now sits alongside JavaScript and TypeScript in the company's Developer Platform, with bindings for Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, and Workflows, plus support for FastAPI, Django, and Flask.

For those who already run serverless Python functions on another cloud, or are considering migrating a small API to Cloudflare's edge, the announcement matters less for the GA label and more for what sits underneath it. Three pieces of engineering made the launch possible, and two of them didn't come from Cloudflare itself.

The packaging standard that was missing

Python Workers run on top of Pyodide, which means any package with a C, C++, or Rust extension needs to be cross-compiled to WebAssembly. Until GA, there was no standardized way to do this, and Cloudflare compiled and hosted these packages on its own, which limited how many were available.

The company proposed PEP 783, which standardizes a platform for Python in browser runtimes called PyEmscripten, accepted after more than a year of discussion. Cloudflare also stabilized Pyodide's build toolchain and added PyEmscripten support to cibuildwheel, allowing package maintainers to build their own wheels without depending on Cloudflare as an intermediary.

A socket bridge for existing drivers

Drivers like aiomysql and asyncpg use the standard library's socket module, which makes POSIX system calls. Inside a WebAssembly sandbox, these calls are just stubs. Cloudflare implemented these syscalls on top of the Workers connect API, with the translation happening at the system call level.

In practice, this means the drivers didn't need any changes to work, and it's this bridge that makes the Hyperdrive integration actually function.

HTTP client running via the browser's fetch

The third piece involved contributions from Cloudflare itself to third-party libraries. Today, requests and httpx route requests through JavaScript's fetch API when running in a WebAssembly environment, which is what allows OpenAI, LangChain, and MCP to work inside a Worker.

The bindings also became more pythonic: sending a dictionary to a Queue previously required manual conversion via to_js with a dict converter; now type conversion happens inside the runtime and the SDK. Web frameworks arrive via connectors rather than their own server: workers.asgi and workers.wsgi translate incoming JavaScript requests into the structures that WSGI and ASGI applications expect.

The friction with urllib3's maintainers

The third piece, the one involving httpx and requests, was the one that drew the harshest reaction. Writing on Hacker News as an urllib3 maintainer, user illia-v explained that the project received large contributions adding support for Pyodide and Emscripten, and later support for JSPI, which is what made requests work at all.

There is a meaningful difference between funding a contribution to an upstream project and funding the upstream maintainers.

illia-v, urllib3 maintainer

This difference shows up in the project's own stance: the Emscripten backend remains experimental in urllib3 and is explicitly out of scope for the security policy. He cites CVE-2025-50182, in which urllib3's redirect controls didn't behave as expected after requests started being routed via fetch, and warns there may be more differences of this kind, since the browser's network semantics differ from urllib3's usual backend.

Cold start: numbers that don't add up

The discussion about startup time came with numbers, not just complaints. Syrus Akbary, founder of Wasmer, which sells a competing WebAssembly platform, revived a concern raised back at the preview launch:

It will be quite hard for them to achieve <100ms startup time with their current architecture.

Syrus Akbary, founder of Wasmer

He said a minimal Python application started in about 60ms on Wasmer Edge versus about 900ms on Cloudflare Workers, in a benchmark published by his own company earlier this year, and asked for current p50 and p95 numbers, with and without native packages.

Dominik Picheta, one of the authors of Cloudflare's post, responded on behalf of the company:

Our memory snapshot implementation has improved the cold starts significantly already.

Dominik Picheta, Cloudflare

He added that sharding reduces how often cold starts happen, and pointed to an earlier post with numbers. Akbary countered that the post reported a startup time of about 1.027 seconds, and asked whether the measurement had been redone since then.

Coupled versioning and extra memory

Akbary's second point of friction was version coupling: Python Workers are locked to the version of Python and Pyodide that workerd embeds. Picheta responded that compatibility flags select between Python 3.12, 3.13, and 3.14, but acknowledged that older versions bring older Pyodide releases, with fewer features, JSPI among them. Akbary read this response as confirming the problem, since the flag also moves workerd along with it.

Memory raised a separate concern from another commenter, dangoodmanUT, who said he hadn't tested the claim:

This likely eats in 10's of MBs more into the worker memory allocation.

dangoodmanUT, Hacker News commenter

The technical debate over the event loop

One of the exchanges settled a technical point rather than a commercial one. Akbary argued that making Python use JavaScript's event loop creates incompatibility, since the two differ in when coroutines execute. Hood Chatham, another author of the post and a Pyodide contributor, responded:

With the WebLoop, Python coroutines stay lazy.

Hood Chatham, Pyodide contributor

He added that the primitive a Python event loop needs is call_later, which maps directly to setTimeout(), and that using JavaScript's loop is necessary because that's where I/O events happen in the runtime. A second loop would block those events.

The same discussion carries the counterpoint to the funding criticism itself. Simon Willison suggested Cloudflare send money to Pyodide. Picheta pointed out that Gyeongjae Choi, another author of the post, is a Pyodide core developer, and that Chatham is a Pyodide contributor employed by Cloudflare: two of the three names on the announcement maintain the very project the runtime runs on.

What changes for Python developers in Brazil

For Brazilian teams that already use Cloudflare Workers in JavaScript and are considering moving a Python API to the edge, GA reduces the risk of depending on a WASM package compiled only by Cloudflare: with PEP 783 and the updated cibuildwheel, it's possible to build your own wheel for a C/Rust dependency that isn't yet available.

The socket bridge also matters in practice: databases accessed via aiomysql or asyncpg work without rewriting the driver, which makes it easier to use Hyperdrive with an existing Postgres or MySQL database. Meanwhile, those who depend on requests or httpx to call AI model APIs get out-of-the-box compatibility with OpenAI, LangChain, and MCP inside the Worker.

What still remains open, according to the InfoQ report, splits into two fronts:

• Cold start and memory: Cloudflare only states that it plans to make the Python runtime more performant and memory-efficient, with no commitment to a specific number, while the competition publishes its own benchmarks with quite different results.
• Upstream maintenance: libraries like urllib3 continue treating the Emscripten path as experimental and outside the security policy, which matters for anyone putting this runtime into production with sensitive data.

Cloudflare published production patterns in the python-workers-examples repository, and the developer documentation now shows Python alongside JavaScript and TypeScript across all of the platform's products.