Cloudflare makes Python first-class in Workers, no JavaScript chaperone required

Why it matters

Cloudflare is removing the language boundary around its edge platform. Python developers can keep familiar frameworks and AI libraries while using Cloudflare's compute, storage, databases and inference services directly.

Cloudflare made Python Workers generally available on September 21st, turning Python into a fully supported language across its developer platform and removing the JavaScript conversion layer that complicated the two-year beta.

The release fits the infrastructure bet that Matthew Prince (@eastdakota), Michelle Zatlyn and Lee Holloway have expanded since founding Cloudflare in 2009. Prince and Holloway first built Project Honey Pot to track how spammers harvested email addresses. Zatlyn, who had worked at Google and Toshiba before meeting Prince at Harvard Business School, helped turn that project into a network for protecting and accelerating websites. Python Workers extends the same model to application code: developers bring familiar tools, while Cloudflare handles where and how the workload runs.

Senior software engineer Gyeongjae Choi, Dominik Picheta and senior systems engineer Hood Chatham authored Cloudflare's GA announcement. Their work addresses a stubborn problem in edge computing. Python has become central to AI development, data processing and backend APIs, while many edge runtimes grew around JavaScript and TypeScript.

Cloudflare is betting that Python developers will accept a WebAssembly runtime when it behaves enough like the environment they already use.

The JavaScript glue is gone

Python Workers execute through Pyodide, a version of CPython compiled to WebAssembly and loaded inside a V8 isolate. Cloudflare has supported WebAssembly in Workers since 2018 and opened Python Workers to beta in April 2024.

During the beta, developers could write Workers in Python, but interactions with Cloudflare services still exposed the JavaScript machinery underneath. Sending a Python dictionary to a Queue, for example, required an explicit conversion into a JavaScript object at the runtime boundary.

Cloudflare now handles that conversion inside the Workers runtime and Python SDK. Python code can call bindings for R2 object storage, D1 databases, Workers AI, Durable Objects, Queues, Workflows and Hyperdrive without a separate JavaScript adapter.

That sounds like a small syntax improvement. It changes whether a Python Worker feels like a supported deployment target or a language shim. The old approach forced developers and coding agents to reason about two object models, even when the application itself was written entirely in Python.

Cloudflare has also added WSGI and ASGI connectors for frameworks including Django, Flask and FastAPI. The Workers platform takes the role normally filled by a web server such as Uvicorn or Gunicorn, translating requests into the structures those Python frameworks expect.

Developers can therefore retain a familiar application structure without running and configuring a separate server process. Cloudflare handles request distribution through Workers, while the connector passes traffic into the Python framework.

Python brings Cloudflare closer to AI application code

The AI angle explains much of the timing. Python remains the default working language for model APIs, orchestration libraries and data tooling. Cloudflare says Python Workers can now run packages including OpenAI's Python library, LangChain and the Python Model Context Protocol package.

Those libraries previously ran into networking limitations because their HTTP clients expected low-level socket behavior that was missing inside the WebAssembly sandbox. Cloudflare patched asynchronous Python HTTP clients to route requests through the Workers Fetch API. For outbound TCP, the current documented path is JavaScript's connect() API rather than a Python socket bridge.

Hyperdrive support for Python Workers now covers PostgreSQL and MySQL. The package and runtime constraints still matter, since WebAssembly compatibility does not make every native socket-dependent Python package portable.

For founders building AI products, the pitch is consolidation. A Python application can receive an API request through FastAPI, call an orchestration library, send inference to Workers AI, place work into a Queue and store output in R2 without introducing a JavaScript service between those steps. Cloudflare's example repository includes an image-generation workflow, an MCP server and a retrieval-augmented generation application.

Cloudflare benefits when each additional binding keeps more of an application's storage, inference, database traffic and background work on its platform. Python support broadens the pool of developers who can adopt that stack without switching languages.

GA followed a month of blocker removal

Cloudflare assembled the GA release through a series of September updates rather than a single runtime switch. According to the Workers changelog, WSGI and ASGI framework support arrived on September 2nd. On September 4th, Cloudflare replaced compressed bundle caps of 3 MB on free plans and 10 MB on paid plans with a 64 MiB uncompressed limit across both plans. Python 3.14 became the default for new Workers using the September 8th compatibility date, and Hyperdrive support followed on September 16th.

The bundle change addressed a practical complaint from Python developers. A GitHub issue filed in July showed how dependencies including pandas, NumPy and Pillow could consume most or all of the former compressed allowance before application code was added.

Cloudflare's package documentation defines the clearest boundary around the GA label. Pure Python packages work, as do packages distributed for the PyEmscripten platform or already included with Pyodide. Packages containing native C, C++ or Rust extensions need WebAssembly-compatible builds.

Chatham authored PEP 783, the accepted Python packaging standard that defines a common pyemscripten platform tag for those builds. That contribution gives package maintainers a standard target beyond Cloudflare alone, reducing the need for Cloudflare engineers to compile and host individual dependencies.

Adoption of the standard is still underway. Cloudflare's package documentation says some packages lack PyEmscripten wheels. Its standard-library documentation says venv and tkinter are unavailable, while multiprocessing and threading can be imported but do not function because of WebAssembly VM limitations. Python Workers also use an ephemeral in-memory filesystem: data disappears when an isolate is destroyed, and files are not shared across isolates, so persistent data belongs in R2, KV or Durable Objects.

Those constraints make Python Workers a better fit for APIs, agents, orchestration and event-driven workloads than for applications designed around local disks, native threads or arbitrary system packages.

Cloudflare wants Workers to feel language-neutral

Prince, Zatlyn and Holloway built Cloudflare by placing a managed network between applications and the public internet. Workers moved application logic onto that network. Python GA widens the strategy by reducing the importance of which language produced that logic.

The engineering pattern is consistent with Cloudflare's recent infrastructure work. RuntimeWire reported on September 18th that four Cloudflare engineers reclaimed more than 100 TB of RAM by changing a six-byte data structure and reducing virtual hashes across the network. Python Workers applies the same habit at the developer layer: absorb complexity inside the platform so customers encounter a simpler interface.

General availability gives teams a supported path to deploy Python frameworks and AI libraries across Workers. Package coverage remains incomplete, and Cloudflare now has to broaden PyEmscripten availability and improve memory efficiency without weakening the isolation and startup characteristics that made Workers useful in the first place.