Cloudflare's Python Workers reach general availability
Cloudflare announced that Python Workers, first introduced two years ago as a way to run Python applications inside the Cloudflare Workers runtime, are now generally available. GA means Python is a first-class, fully supported language on the Cloudflare Developer Platform, on the same footing as TypeScript: developers can bring existing Python code, libraries and design patterns and connect them directly to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues and Workflows, and can even nest a Python Worker inside another Worker using Dynamic Workers.
The update replaces a manual conversion step at the RPC boundary. Previously, calling a Cloudflare binding from Python meant explicitly converting Python objects into JavaScript ones, for example wrapping a dictionary sent to a Queue in pyodide.ffi.to_js with a dict_converter. Cloudflare says this glue code required Python developers to keep the JavaScript environment in mind while writing Python Workers and was a common source of error for both humans and AI agents. That conversion is now handled inside the Workers runtime and the Python SDK itself, so the same call becomes a plain self.env.QUEUE.send({"key": "value"}) with no JavaScript involved.
Python Workers can now also run FastAPI, Django and Flask directly, through built-in workers.asgi and workers.wsgi connectors that translate an incoming JavaScript request into the WSGI or ASGI structures those frameworks expect, then pipe the response back out. Cloudflare frames the Workers platform itself as replacing the usual Uvicorn or Gunicorn server layer, since its global network already handles load balancing and scaling; the connectors work with any WSGI- or ASGI-compliant framework, not only the three named.
On the data and packaging side, Python Workers previously had no TCP socket support, so database drivers such as aiomysql or asyncpg could not open connections at all inside the WebAssembly sandbox. Cloudflare built socket system calls on top of its own Workers connect API to bridge standard Python socket operations to the runtime, which now lets a Worker reach Postgres or MySQL through a Hyperdrive binding using ordinary drivers. Separately, because any Python package with native C, C++ or Rust extensions has to be cross-compiled to WebAssembly to run in a Worker, Cloudflare proposed PEP 783, a standard for a "PyEmscripten" platform for running Python in browser runtimes. The proposal was accepted after more than a year of discussion, and Cloudflare has also stabilized the Pyodide build toolchain and added PyEmscripten support to cibuildwheel so other package maintainers can build and publish compatible wheels themselves.
The same missing socket support had blocked the HTTP clients, such as requests and httpx, that libraries like openai, langchain and mcp depend on to reach external APIs. Cloudflare says it contributed upstream changes so those clients route requests through the JavaScript fetch API instead, which combined with the new socket support makes openai, langchain and mcp usable natively inside Python Workers, including alongside Workers AI for serverless GPU inference or proxied through Cloudflare's AI Gateway.
Key facts
- Python Workers, introduced two years ago, have reached general availability, making Python a first-class, fully supported language on Cloudflare's Developer Platform.
- Cloudflare bindings, including R2, D1, Hyperdrive, Durable Objects, Queues, Workflows and Workers AI, now work natively from Python without the manual JavaScript conversion code GA removes.
- FastAPI, Django and Flask can run directly in Python Workers through built-in workers.asgi and workers.wsgi connectors.
- New low-level socket support lets Python Workers connect to Postgres and MySQL through Hyperdrive and lets AI libraries such as openai, langchain and mcp reach external APIs.
- Cloudflare proposed PEP 783, a PyEmscripten packaging standard for running Python in browser runtimes, which was accepted after more than a year of discussion.
Why it matters
General availability moves Python from an experimental option to a language Cloudflare treats as equal to TypeScript on its platform. It removes two concrete blockers that kept real Python applications from running well as Workers: the manual JavaScript conversion glue needed to call platform bindings, and the missing TCP socket support that shut out database drivers and the HTTP clients AI libraries rely on. That clears the way for developers to bring frameworks and AI stacks they already use rather than rewriting them for the runtime.
Who it affects
Python developers building on Cloudflare Workers, particularly teams porting existing FastAPI, Django or Flask applications, apps backed by Postgres or MySQL, and AI or agent projects built on openai, langchain or mcp. It also affects Python package maintainers: Cloudflare's PEP 783 proposal and its added support for cibuildwheel change how anyone ships a WebAssembly-compatible wheel, not just how Cloudflare's own runtime consumes one.
How to use it
An existing FastAPI or Flask app can be run as a Worker by wiring it up with workers.asgi.entrypoint(app); a synchronous framework such as Django uses workers.wsgi.entrypoint instead. Cloudflare bindings can now be called as plain Python objects, for example self.env.QUEUE.send({"key": "value"}), with no conversion helpers needed. Database access goes through a Hyperdrive binding using standard drivers like aiomysql, connecting with the host, port, user, password and database values Hyperdrive supplies. The source gives no pricing or billing details for Python Workers, so cost is not covered here.
How solid is it
The claims come from Cloudflare's own blog post announcing the GA milestone, describing its own product and the engineering behind it, including the socket syscall bridge, the asgi and wsgi connectors, and the PEP 783 standardization process. The post gives no independent benchmark or performance comparison against JavaScript Workers, no named customer list beyond a general reference to "many developers," and no calendar date for the announcement itself beyond "today."
Risks and caveats
Python Workers still run inside a WebAssembly sandbox via Pyodide, so any package with native C, C++ or Rust extensions needs a WebAssembly-compatible build to work at all. Cloudflare says the wider ecosystem is still adopting the new PyEmscripten standard it proposed, meaning not every Python package is supported yet, and it directs users who hit an unsupported package to report it on Discord or GitHub rather than claiming full coverage.
“It means Python is now a first-class, fully supported language on the Cloudflare Developer Platform.”
— Cloudflare, Python Workers GA announcement