Skip to content

Python Workers are now generally available

Summary

Cloudflare made Python Workers generally available (GA) — Python is now a first-class, fully supported language on the Cloudflare Developer Platform, running a Wasm-compiled Python interpreter (Pyodide) inside the Workers runtime rather than a native CPython process. GA is defined by four capabilities that each closed a gap left by the 2023 preview: (1) native Cloudflare bindings — the type-conversion across the Python↔JavaScript RPC boundary is now encapsulated inside the runtime and SDK, so env.QUEUE.send({"key": "value"}) "just works" with no to_js glue; (2) web frameworks — FastAPI/Django/Flask run via built-in workers.asgi / workers.wsgi connectors that bridge incoming JS requests into the standard ASGI/WSGI interfaces, with the Workers platform itself acting as the web server (no uvicorn/gunicorn); (3) relational DB drivers via Hyperdrive — a socket-syscall shim implements the POSIX socket calls that aiomysql/ asyncpg rely on (normally stubbed-to-fail inside a Wasm sandbox) by translating them into the Workers connect() TCP API; and (4) an expanded Wasm package ecosystem via PEP 783 / PyEmscripten, a standardized platform for cross-compiling native-extension packages to WebAssembly (with cibuildwheel support), replacing Cloudflare's hand-built package hosting. Combined HTTP-client fetch-routing contributions also unblock openai/langchain/ mcp for building AI agents on-platform.

Key takeaways

  1. Python Workers run a Wasm-compiled Python interpreter, not native CPython. Because Workers has supported WebAssembly since 2018, Cloudflare compiled the Pyodide interpreter to Wasm and runs it inside the same Workers runtime that hosts JavaScript/TypeScript — the goal being to make writing a Worker in Python "as simple as it is in TypeScript" (Source: sources/2026-09-21-cloudflare-python-workers-are-now-generally-available).

  2. Bindings are now Pythonic — the JS↔Python type conversion moved into the runtime. Preview code had to explicitly marshal at the RPC boundary (self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))), "a common source of error for both humans and AI agents." GA encapsulates the entire type-conversion process inside the runtime + Python SDK, so self.env.QUEUE.send({"key": "value"}) works directly across all bindings — no JavaScript in the Python source.

  3. The Workers platform is the web server; connectors are a thin ASGI/WSGI bridge. Python's WSGI (sync) / ASGI (async) contract lets frameworks be server-agnostic — in a normal deployment uvicorn/gunicorn handle concurrency and connections. On Workers, the global network already does load balancing and scaling, so instead of running a server inside the Worker, workers.asgi and workers.wsgi "translate the incoming native JavaScript request into the standard WSGI/ASGI structures that Python applications expect, and seamlessly pipe the response back out with minimal overhead." Any WSGI/ASGI framework works, not just FastAPI/Django/Flask. Entry point: Default = asgi.entrypoint(app).

  4. A socket-syscall shim unblocks TCP database drivers inside the Wasm sandbox. Drivers like aiomysql/asyncpg use the stdlib socket module, which normally issues POSIX networking syscalls to the OS. Inside a Wasm sandbox those syscalls are stubs that always fail, so any standard socket open would fail immediately. Cloudflare implemented socket syscalls at the system-call level on top of the Workers connect() API — translating "opening a connection and reading bytes" into the runtime's JS calls — so "your database drivers don't have to know about the underlying implementation at all." This shim is what makes the Hyperdrive integration possible; the Worker reads hd.host/port/user/password/database off the Hyperdrive binding and connects with a familiar driver.

  5. PEP 783 / PyEmscripten standardizes cross-compiling native packages to Wasm. Any package with native C/C++/Rust extensions must be cross-compiled to Wasm to run in Python Workers. Previously there was no standard way to do this, so Cloudflare's team had to manually compile and host custom Wasm packages, sharply limiting the usable package set. Rather than build Workers-only packages, Cloudflare proposed and (after >1 year of discussion) got accepted PEP 783 — the PyEmscripten platform — so maintainers can build and publish once for all PyEmscripten-implementing environments. They also stabilized the Pyodide build toolchain and added PyEmscripten support to cibuildwheel. This is an upstream-the-standard play — the whole Python-on-Wasm community benefits, not just Cloudflare.

  6. AI-agent libraries now work by routing HTTP clients through Wasm fetch. openai/langchain/mcp rely on HTTP clients (requests/httpx) that previously failed for lack of low-level socket support. Cloudflare contributed upstream so these clients route requests directly through the JavaScript fetch API in Wasm environments; combined with the new socket support, "the entire networking stack works seamlessly." Agents can call Workers AI for serverless GPU inference or proxy through AI Gateway.

  7. Composable full-stack patterns are the headline use case. Cloudflare shipped a python-workers-examples repo: an image-to-image generator (request → Queue → Workflows orchestrating Workers AI → store to R2); a real-time Bluesky Jetstream WebSocket consumer backed by a Durable Object for long-lived connection state; an MCP server; and a RAG system on Workers AI + Vectorize.

Systems / concepts / patterns extracted

  • Systems: Cloudflare Workers (host runtime), Pyodide (Wasm Python interpreter — new page), WebAssembly (sandbox + compile target), Emscripten (Pyodide's toolchain; PyEmscripten platform), Hyperdrive (DB connectivity, now reachable from Python), Workers AI, FastAPI, Queues, Workflows, R2, Durable Objects, MCP. Mentioned in prose only (below the page bar): Django, Flask (WSGI/ASGI frameworks), aiomysql/asyncpg (drivers), openai/langchain/mcp (agent libs), cibuildwheel, Dynamic Workers, Vectorize.
  • Concepts: serverless compute (Python on a managed, autoscaling edge runtime), stateless compute (platform-as-web-server: no in-Worker server process), Wasm sandbox (why raw sockets fail and must be shimmed).
  • Patterns: managed service as native binding (Hyperdrive-as-binding, now Pythonic), upstream the standard (PEP 783 / PyEmscripten + cibuildwheel + HTTP-client fetch-routing rather than Workers-only forks).
  • Prose-only design idioms (deliberately NOT minted as pages — single-source, implementation-specific): the ASGI/WSGI application-server contract as the seam a serverless platform slots into (canonical Python concept but only one source here — recorded as a tag + this prose); the socket-syscall shim over a runtime connect() API (translate POSIX socket ops into host JS calls at the syscall level so unmodified drivers work in Wasm); encapsulate RPC type-conversion in the runtime (remove the cross-language marshalling from user code). Per AGENTS.md taxonomy gate, these are article-specific mechanics captured as prose, not new concept/pattern pages.

Operational notes / numbers

  • GA milestone: Python Workers went from 2023 preview to GA; Python is now a first-class supported language alongside JS/TS on the Developer Platform.
  • Bindings supported Pythonically: Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows.
  • Frameworks: FastAPI (ASGI), Django (WSGI), Flask, and any WSGI/ASGI framework.
  • PEP 783: accepted after >1 year of discussion; standardizes the PyEmscripten cross-compilation platform; cibuildwheel gained PyEmscripten support.
  • No new hard perf numbers — this is a GA/capability post, not a benchmark post. Roadmap: more performant + memory-efficient Python Workers, more packages.

Caveats

  • Feature/GA-launch post. It clears scope on architecture depth (WASM interpreter model, ASGI/WSGI bridge design, socket-syscall shim, PEP 783 cross-compilation) — well above the 20% architecture bar — but it is still a launch announcement, so claims are Cloudflare's own and it reports no independent benchmarks.
  • Ecosystem still maturing: not every PyPI package has a PyEmscripten wheel yet; Cloudflare is working with maintainers and takes requests via Discord/GitHub.
  • Wasm sandbox constraints remain — the socket shim and fetch-routing are workarounds for the fact that a Wasm sandbox has no ambient OS networking; packages assuming native syscalls beyond what's shimmed may still not work.

Source

Last updated · 766 distilled / 2,225 read