Cloudflare makes Python a first-class Workers language

Python stops being the second-class citizen

Cloudflare declared Python Workers generally available on 21 September, two years after it first offered a way to run Python applications inside the Workers runtime. Generally available, in Cloudflare's telling, means Python is now a first-class and fully supported language on its developer platform: the code, libraries and design patterns a Python developer already knows can be pointed at Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows and the rest of the stack.

The glue code is gone

The most practical change is the disappearance of a layer of conversion code. Until now, using Cloudflare bindings from Python meant translating Python objects into TypeScript objects by hand at the boundary between the two: sending a Python dictionary into a queue required importing to_js and a dict converter before the call would work. Cloudflare says that forced Python developers to hold the JavaScript environment in their heads while writing Python, and it calls the glue "a common source of error for both humans and AI agents". The conversion now happens inside the runtime and the Python SDK, so a queue send takes a Python dictionary and nothing else.

FastAPI, Django and Flask, without a web server

Python web frameworks now run in a Worker. Cloudflare provides workers.asgi and workers.wsgi connectors that translate an incoming request into the interfaces those frameworks expect and pipe the response back out. Nothing else is needed - no uvicorn, no gunicorn - because the Workers platform itself is the web server, doing the concurrency and load balancing on Cloudflare's network. The connectors work with any framework that speaks WSGI or ASGI, not only the three Cloudflare names.

Databases arrive through a socket shim

The blocker for real applications was sockets. Python database drivers such as aiomysql and asyncpg depend on the standard library's socket module, and inside a WebAssembly sandbox those POSIX networking calls are stubs that fail. Cloudflare implemented socket system calls on top of the Workers connect API, so when a driver opens a TCP connection it is translated into the JavaScript calls the runtime understands. That is what makes the Hyperdrive integration - connection pooling for PostgreSQL and MySQL - usable from Python with ordinary database drivers.

The same problem had a second face. OpenAI, LangChain and Model Context Protocol libraries reach the network through HTTP clients such as requests and httpx, which also needed socket support. Cloudflare contributed upstream so those clients can route requests through the JavaScript fetch API in WebAssembly environments, and says openai, langchain and mcp now run natively in a Python Worker, where they can be paired with Workers AI inference or Cloudflare AI Gateway.

Packages, and a standard instead of an index

Python packages with native C, C++ or Rust extensions have to be cross-compiled to WebAssembly, and there was no standard way to do it, which left Cloudflare hand-compiling and hosting its own builds and limited what developers could import. Rather than build a package index only its own runtime could use, Cloudflare proposed PEP 783, which standardises a pyemscripten platform tag for Python packages built for Pyodide-style runtimes. The proposal was accepted after more than a year of discussion, the Pyodide build toolchain was stabilised for package maintainers, and pyemscripten support was added to cibuildwheel so other projects can build for it.

Cloudflare has also published a repository of production patterns: an AI image generator that queues requests and orchestrates Workers AI through Workflows with results in R2, a Worker that consumes the Bluesky Jetstream WebSocket and keeps the connection alive behind a Durable Object, an MCP server, and a retrieval-augmented generation system built on Vectorize. Its developer documentation now carries Python example code almost everywhere a TypeScript example exists, switchable in place. The company says the next work is performance, memory efficiency and more packages.

Our opinion

The genuinely interesting part of this launch is a standard, not a runtime. Cloudflare could have shipped a private package index, kept Python Workers a walled garden and collected the lock-in; instead it wrote a platform tag, argued for it in public for a year and pushed support into cibuildwheel, which improves the odds for every WebAssembly Python deployment including the ones that never touch Cloudflare. The socket shim is the other quiet win: frameworks are the demo, databases are the job, and no one was going to rewrite a PostgreSQL driver to suit a sandbox. The sceptical question is economics. A CPython interpreter inside a WebAssembly sandbox is not the same machine as a small TypeScript Worker, and "first-class language" is a statement about support rather than parity until Cloudflare publishes cold-start and CPU-cost guidance for Python specifically. Watch what developers do with the free-tier limits before believing the migration has started.