Cloudflare makes Python a first-class Workers language after a two-year preview

Python has run on Cloudflare Workers for two years, but only as a preview, and the seams showed. Sending a dictionary into a queue meant importing Pyodide's foreign function interface and converting the object into a JavaScript one by hand. On September 21, 2026 Cloudflare declared Python generally available on Workers and moved that conversion into the runtime, where a Python developer no longer sees it.

What changed at the boundary

The Workers runtime is built on V8, and Python runs inside it as a Pyodide interpreter compiled to WebAssembly. Every call from Python into a Cloudflare service therefore crosses a boundary between two object models. Until now that crossing was the developer's problem: a queue send needed to_js with an explicit dict_converter, and the JavaScript environment had to stay in mind while writing Python.

Cloudflare moved the conversion into the runtime and the Python SDK, so a plain dictionary passed to a queue binding now works on its own. The company says the old pattern was a common source of error for both people and coding agents. The same bindings reach R2, D1, Hyperdrive, Durable Objects, Queues, Workflows and Workers AI.

Databases, over sockets that finally exist

Python database libraries call the standard library's socket module, which inside a WebAssembly sandbox resolves to stubs that always fail. Cloudflare implemented those system calls against the Workers connect API, so a library that opens a TCP connection is translated into the runtime's own call without being changed. That is what makes the Hyperdrive binding usable from Python at all.

The same missing layer was why the openai, langchain and mcp packages did not work. They depend on HTTP clients such as requests and httpx, and Cloudflare contributed changes upstream so those clients route their requests through the JavaScript fetch API when they run in WebAssembly.

• aiomysql and asyncpg connect through a Hyperdrive binding, using the host, port, user, password and database name it supplies.
• The workers.asgi connector runs FastAPI and any other ASGI application, and workers.wsgi runs Django, Flask and the rest of the WSGI world.
• Cloudflare's documentation now carries a Python example next to nearly every TypeScript one.

A standard for Python on WebAssembly

Packages with extensions written in C, C++ or Rust have to be cross-compiled before they run in a WebAssembly sandbox, and there was no agreed way to do that. Cloudflare's team compiled and published those builds itself, which capped how many packages a Python Worker could import.

The company proposed PEP 783, which defines a platform target called PyEmscripten, and the proposal was accepted after more than a year of discussion. Support for that target was added to cibuildwheel, so a maintainer can publish a WebAssembly build the same way as any other. Cloudflare says the ecosystem is still adopting it.

What still does not work

Two standard library modules import and then do nothing. Cloudflare's documentation lists multiprocessing and threading as present but non-functional because of the WebAssembly virtual machine. Several others are removed outright, among them fcntl, termios and venv, and pty and tty fail to import because they depend on a module that is gone.

This suggests the real limit is shape rather than scale. Code that fans work out across threads has to be rewritten around what the platform offers, while code that waits on the network fits unchanged. Cloudflare says performance and memory work comes next, without naming a figure for either.