Cloudflare's Python Workers Are Now Generally Available

Cloudflare just announced Python Workers are generally available after two years of development. The headline isn't "Python now runs on Workers" — that already worked. It's that Python can finally use Cloudflare's bindings (D1, R2, Queues, Hyperdrive) without a single line of JavaScript glue code.

What happened

According to the official blog post published September 21, Cloudflare first introduced Python Workers two years ago, running on Pyodide — a WebAssembly-compiled Python interpreter. Getting from that experimental release to GA meant closing three gaps: bindings required manual type conversion, standard web frameworks couldn't run, and missing TCP socket support meant database drivers didn't work at all.

All three are now resolved.

Bindings finally work the Pythonic way

Sending a Python dict to a Cloudflare Queue used to require this:

from pyodide.ffi import to_js
import js

self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))

Now it's just:

self.env.QUEUE.send({"key": "value"})

The entire type-conversion layer is now baked into the runtime and Python SDK. For developers, that means not having to keep a mental model of "I'm actually running inside a JavaScript environment" while writing Python — a common source of bugs for both humans and AI coding agents, per Cloudflare's own account.

Real FastAPI, Django, and Flask support

Python Workers now support workers.asgi for async apps (FastAPI) and workers.wsgi for sync apps (Django, Flask). This doesn't spin up a Python server inside the Worker — instead, it uses the existing WSGI/ASGI standard to translate the native JavaScript request into the structure your framework expects, then pipe the response back out. The Workers platform itself handles load balancing and scaling; you just write application logic.

from workers import asgi

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return await asgi.fetch(app, request, self.env)

Postgres and MySQL over Hyperdrive

This is the most technically interesting part. Python Workers run inside a WebAssembly sandbox, and database drivers like asyncpg or aiomysql normally open TCP sockets via Python's standard socket module — something that doesn't exist in Wasm. Cloudflare's fix: reimplement the socket syscalls to route through the Workers connect API. Drivers work exactly as they do anywhere else; they never need to know about the translation layer underneath.

Paired with Hyperdrive, a Python Worker can now talk directly to a production Postgres or MySQL database without a separate proxy.

Fixing the package ecosystem: PEP 783 and PyEmscripten

The remaining blocker: packages with native C/C++/Rust extensions need to be cross-compiled to WebAssembly, and there was no standard way to do that — Cloudflare had to manually build and host these packages itself. To fix this at the root, Cloudflare proposed PEP 783, standardizing a PyEmscripten platform for running Python in browser-like Wasm runtimes. After more than a year of discussion, the PEP was accepted. Cloudflare also added PyEmscripten support to cibuildwheel, the widely-used tool for building cross-platform wheels, making it easier for any package maintainer to target this platform.

This is upstream work that benefits the whole Pyodide community, not just Cloudflare's own platform.

Python-native AI agents and pipelines

Libraries like openai, langchain, and mcp rely on HTTP clients (requests, httpx) to reach external APIs — which didn't work in Python Workers due to missing low-level socket support. Cloudflare contributed upstream fixes so these clients route requests through the JavaScript fetch API when running in WebAssembly. Combined with the Hyperdrive socket bridge, the entire networking stack now works cleanly inside Python Workers.

So what does this mean for you?

• No stack rewrite needed: teams running FastAPI or Django can deploy straight to Cloudflare's edge network without touching TypeScript or learning a new API surface
• Production databases just work: Hyperdrive plus familiar drivers (asyncpg, aiomysql) means no data-layer rearchitecture just to go serverless
• Native Python AI agents: langchain, mcp, and openai run as-is, and can pair with Workers AI for inference on the same network — no separate server needed to host the agent
• Still has gaps: packages without a PyEmscripten wheel simply won't run yet — the ecosystem is mid-transition, not every PyPI package is ready

What's notable here isn't "another runtime added Python support" — GitHub Actions, Lambda, and Vercel have all done that for years. The difference is Cloudflare chose the harder path: solving the native-extension-on-WebAssembly problem at the root through an actual PEP, instead of patching it for their platform alone. If PyEmscripten gets picked up more broadly across Pyodide and browser runtimes, this could end up mattering well beyond Cloudflare Workers.

Key Takeaways

• Python Workers reached GA after two years of development, running on Pyodide (Python compiled to WebAssembly)
• Cloudflare bindings (D1, R2, Queues, Hyperdrive) now work with native Python syntax, no manual JavaScript conversion needed
• FastAPI, Django, and Flask run as-is via workers.asgi/workers.wsgi, no app rewrite required
• Hyperdrive connects Python Workers directly to production Postgres/MySQL databases
• PEP 783 (PyEmscripten) was accepted, paving the way for native-extension packages to build for WebAssembly
• Remaining gap: packages without a PyEmscripten wheel still won't run

---

Content assisted by AI (Amy 🌸). Reviewed by the author.