Cloudflare says Python Workers are now generally available, making Python a first-class, fully supported language on its developer platform. The company’s announcement describes native access to services including Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, and Workflows. It also says Python applications can use FastAPI, Django, Flask, and other frameworks built on the ASGI or WSGI interfaces.
Supports the discussion of native access to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, and Workflows. Credit: blog.cloudflare.com.
The central architectural idea is not to run a conventional Python application server inside every Worker. Cloudflare says it uses a WebAssembly-compiled Python interpreter based on Pyodide, while the Workers platform handles request routing and scaling. Its workers.asgi and workers.wsgi connectors translate JavaScript request objects into the structures expected by Python frameworks, then convert the application response back for the Workers runtime. That design lets developers retain familiar framework code, but it also makes compatibility dependent on the runtime, connectors, and supported Python packages rather than on an ordinary operating-system deployment.
A major change is the removal of explicit JavaScript conversion code at many Cloudflare binding boundaries. Cloudflare says Python dictionaries, queues, and other platform objects can now be passed through the Python SDK in a more idiomatic way. The announcement contrasts the new approach with earlier code that required developers to convert Python data into JavaScript objects manually at the RPC boundary. For teams evaluating the platform, that is potentially more important than syntax alone: it affects how much runtime-specific code must be maintained around otherwise ordinary Python logic.
Database access also depends on a compatibility layer. Cloudflare says Python Workers previously lacked the low-level socket operations expected by drivers such as aiomysql and asyncpg. It describes a socket implementation that translates Python socket calls into Workers connect API operations, allowing supported drivers to communicate with PostgreSQL or MySQL through Hyperdrive. This is a targeted solution to a WebAssembly constraint, not evidence that every database driver or database feature will behave exactly as it does on Linux.
Directly illustrates the socket bridge that lets supported Python drivers use PostgreSQL or MySQL through Hyperdrive. Credit: blog.cloudflare.com.
The package story is similarly significant but still incomplete. Cloudflare explains that Python packages containing native C, C++, or Rust extensions must be cross-compiled for WebAssembly. It says the accepted PEP 783 proposal standardizes the PyEmscripten platform, while work on the Pyodide build toolchain and cibuildwheel is intended to make compatible wheels easier for maintainers to produce. Those steps could reduce the need for Cloudflare to compile packages individually, but the company also acknowledges that ecosystem adoption is ongoing. A package’s presence in the normal Python ecosystem therefore does not, by itself, establish that a usable WebAssembly build is available.
Cloudflare also claims that changes allowing HTTP clients to use the JavaScript fetch API make libraries such as openai, langchain, and mcp usable in Python Workers. Combined with Workers AI and the AI Gateway, the company presents Python as a practical language for edge-hosted AI orchestration and pipelines. That claim is useful for understanding the intended workload, but it should not be read as a guarantee that every third-party integration, protocol, or dependency will work without adaptation.
The most important unanswered operational question is performance under real workloads. The announcement says Cloudflare plans to improve Python Workers’ speed and memory efficiency, but the supplied source includes no cold-start measurements, memory comparisons, throughput data, or limits for representative applications. It therefore does not establish whether a Pyodide-based Worker is appropriate for a latency-sensitive service, how much memory a particular dependency set consumes, or how its costs compare with a conventional container or JavaScript Worker. Those questions require workload-specific testing rather than inference from the general-availability label.
For developers, the practical evaluation is narrower than asking whether Python now runs everywhere Cloudflare’s platform runs. The relevant tests are whether the required Python version and packages have WebAssembly builds, whether the application’s framework uses a supported ASGI or WSGI path, whether database and network dependencies work through the provided bridges, and whether the resulting latency and memory profile meets the service’s requirements. Cloudflare’s announcement establishes the company’s supported product direction and describes the mechanisms it has built; it does not independently validate every compatibility or performance outcome.