Stackmaven
Launch Published 19d ago ·

Cloudflare's Python Workers reach GA after a two-year beta, and the JavaScript glue layer is finally gone

Cloudflare made Python Workers generally available on September 21, ending a two-year preview. FastAPI, Django, and Flask now run on the Workers edge runtime, and Cloudflare's storage and AI bindings are callable from Python without a JavaScript shim.

By Stackmaven

Cloudflare made Python Workers generally available on September 21, ending a preview that ran for roughly two years. The headline is that Python is now a first-class language on Workers rather than an experiment, but the change that matters to developers is narrower and more concrete: the JavaScript shim that earlier Python Workers leaned on is gone. You can now call Cloudflare’s platform bindings directly from Python, and run a FastAPI, Django, or Flask app on the same edge runtime that serves JavaScript Workers.

What “first-class” removes

Earlier Python Workers worked by wrapping Python around a JavaScript core, so reaching Cloudflare’s storage, queues, or AI features meant crossing into JavaScript glue code. The GA release lets Python call those bindings natively. D1, R2, Workers AI, Queues, Durable Objects, and Workflows are all reachable from Python directly, and databases are reachable through Hyperdrive using standard Python drivers rather than a Cloudflare-specific client. Web frameworks come along for the ride: FastAPI, Django, and Flask run through ASGI and WSGI connectors, so a service written against those frameworks is closer to a deploy-target change than a rewrite. The libraries developers reach for in AI work, including the openai, langchain, and mcp packages, run natively too.

Under the hood, none of this is CPython on a server. Cloudflare compiles Python to WebAssembly using Pyodide and runs it inside its V8-based workerd runtime, and the release credits Pyodide’s core maintainers, which reads as investment in the upstream project rather than a fork. As the independent developer Simon Willison noted in his write-up, that architecture carries hard limits: both multiprocessing and threading are non-functional in the WebAssembly VM, so code that depends on either will not port cleanly.

Where the edges still are

GA means supported, not unconstrained. Cloudflare’s own framing points to an ecosystem still catching up. Python packages need to be available as WebAssembly-compatible builds, and the standardization effort behind that, PEP 783, is still being adopted. Packages with native C, C++, or Rust extensions require cross-compilation and are not all available yet, so a dependency tree that pulls in a compiled library may still hit a wall. The announcement is also quiet on cold-start behavior and Python-specific pricing, the two numbers a team would want before moving a production service. The honest read is that the runtime and the bindings are ready, while the package ecosystem and the operational envelope are the parts to test against your own app.

What it means for developers

For Python developers, this opens a door that JavaScript and TypeScript have had to themselves on Cloudflare’s edge. A team running FastAPI or Django can now put that code on Workers, wire it to R2, D1, and a Postgres database through Hyperdrive, and call Workers AI, all in Python. That is most interesting for two groups: teams that already live in Cloudflare’s platform and wanted to write edge logic in Python instead of context-switching to JavaScript, and Python-first teams evaluating edge deployment who previously had thinner options than the Node ecosystem offered. The threading and multiprocessing limits mean this is not a drop-in host for every Python service, and the package constraints mean the safest first candidates are I/O-bound web services with lean dependency trees rather than compute-heavy jobs that pull in large native libraries.

What to watch

The signals over the next quarter are how quickly the WebAssembly package ecosystem fills in under PEP 783, whether cold starts and pricing for Python Workers land close to their JavaScript equivalents once teams measure real traffic, and whether the framework connectors hold up under production load rather than demos. The broader move is Cloudflare treating Python as a peer runtime on the edge, which pressures the assumption that serious edge work has to be written in JavaScript. Stackmaven’s follow-up will revisit around December 21.

Sources cited
  1. Python Workers are now generally available (Cloudflare) blog.cloudflare.com
  2. Cloudflare Python Workers are now generally available (Simon Willison) simonwillison.net
esc