Cloudflare made Python a fully supported language on its Workers platform on September 21, moving Python Workers out of beta after two years of development. The production release can run FastAPI, Django and Flask applications, connect to PostgreSQL and MySQL through Hyperdrive, and use Python AI libraries including OpenAI, LangChain and the official Model Context Protocol package.
The change makes Workers a more credible deployment target for Python APIs and lightweight AI services. It does not turn Cloudflare’s WebAssembly runtime into a conventional Linux server, however. Developers still need to check package compatibility, memory and CPU limits, database behavior and assumptions about local storage before moving an existing application.
What changed with Python Workers GA
Python Workers run CPython through Pyodide, which compiles the interpreter and compatible packages to WebAssembly. That architecture was already available during the beta. The general-availability release fills in several pieces that determine whether a runtime can support production applications rather than demonstrations.
Cloudflare now treats Python as a first-class language across the developer platform. Python code can access Workers AI, R2 object storage, D1 databases, Durable Objects, KV, Queues, Workflows, secrets and service bindings. The runtime also converts common values across the Python-JavaScript boundary automatically. A Python dictionary can now be sent to a Queue binding directly, instead of requiring explicit conversion into a JavaScript object.
That detail removes a surprisingly common source of failure. Python code still runs inside a platform whose underlying APIs are implemented in JavaScript, but application developers no longer need to keep writing interop glue for normal binding operations.
FastAPI, Django and Flask no longer need a separate web server
Cloudflare added built-in ASGI and WSGI connectors. FastAPI and Starlette applications use the asynchronous workers.asgi connector, while Django, Flask and other synchronous frameworks can use workers.wsgi.
A minimal FastAPI Worker can look like this:
from fastapi import FastAPI
from workers import asgi
app = FastAPI()
@app.get("/health")
async def health():
return {"status": "ok"}
Default = asgi.entrypoint(app)On a normal virtual machine or container, an ASGI server such as Uvicorn accepts network traffic and hands requests to the application. In Workers, Cloudflare’s runtime already performs that role, so the connector adapts incoming Worker requests to the framework interface. Developers can keep familiar routing, validation and middleware patterns without trying to launch a long-running server process inside the isolate.
This is best viewed as framework compatibility, not automatic lift-and-shift support for an entire server environment. Code that depends on process management, operating-system daemons, writable persistent directories or unsupported native extensions still needs redesign.
Database access is useful, with important boundaries
Python Workers can now reach existing PostgreSQL and MySQL databases through Cloudflare Hyperdrive. Cloudflare built a socket bridge that maps Python networking operations in the WebAssembly sandbox to the Workers TCP connect() API. That enables familiar database drivers instead of requiring an HTTP-only database service.
The company recommends asyncpg for PostgreSQL and aiomysql for MySQL. It has also tested pg8000, psycopg and pymysql. A project using Hyperdrive must set a Workers compatibility date of September 8, 2026 or later, add a Hyperdrive binding to its Wrangler configuration and use the connection values exposed through that binding.
There are two caveats worth checking before a migration. Cloudflare’s current documentation supports synchronous SQLAlchemy but not asynchronous SQLAlchemy because the runtime does not yet support greenlet. Synchronous database operations also need serialization with a lock so they do not create unsafe concurrent access inside the isolate. Applications built around async ORM sessions should test the lower-level async drivers or retain their existing deployment platform for now.
Python packaging is broader, but not universal
Pure-Python packages are the easy case. Packages containing C, C++ or Rust extensions need WebAssembly-compatible builds, and that has historically restricted what Pyodide-based runtimes can install.
Cloudflare helped develop PEP 783, which defines the PyEmscripten platform for Python running on WebAssembly. Package maintainers can publish PyEmscripten wheels to PyPI, while cibuildwheel now has tooling to produce them. Python Workers can install pure-Python and PyEmscripten packages from PyPI as well as packages bundled with Pyodide.
Adoption is still in progress. If a dependency relies on a native extension and does not publish a compatible wheel, it may not run. That is a build-time check worth performing before any architecture decision: inventory direct and transitive dependencies, then verify that every required native package has a PyEmscripten or Pyodide build.
AI libraries now work without custom HTTP plumbing
Libraries such as openai, langchain and mcp depend on HTTP clients including requests and httpx. Those clients previously ran into missing low-level networking operations in Python Workers. Cloudflare contributed changes that let the clients route requests through the JavaScript Fetch API in WebAssembly environments, while the new socket work covers lower-level TCP use cases.
The practical result is that a Python Worker can call an external model API, use Cloudflare Workers AI, place work on a Queue, store files in R2 and coordinate multi-step jobs with Workflows without a TypeScript adapter. Cloudflare’s examples include an image-generation pipeline, a Bluesky Jetstream consumer backed by a Durable Object, an MCP server and a retrieval-augmented generation application using Vectorize.
Those are good matches for the platform because they are dominated by network I/O and managed services. Large local models, heavy data-frame operations and memory-intensive scientific workloads are a different matter.
The limits that should decide whether you migrate
General availability changes the support promise, not the Workers resource model. Each isolate has 128 MB of memory, including WebAssembly allocations. Free-plan HTTP requests receive 10 milliseconds of CPU time; paid Workers allow up to five minutes, with a 30-second default. Waiting for network I/O does not consume CPU time, which favors APIs, orchestration and database-backed request handlers over sustained local computation.
The file system is also ephemeral. Python’s normal file APIs work, but data disappears when the isolate is destroyed. Durable data belongs in R2, D1, KV, a database reached through Hyperdrive or another external service.
Before moving a service, check these five items:
- Dependency compatibility: confirm that every native package has a WebAssembly-compatible wheel.
- Memory behavior: test realistic payloads and concurrency against the 128 MB isolate ceiling.
- CPU profile: separate I/O wait from actual Python compute and set a paid-plan CPU limit deliberately.
- State assumptions: replace local files, process memory and background daemons with platform storage and workflow services.
- Database stack: verify the exact driver and ORM mode, especially if the application uses async SQLAlchemy.
A quick way to test an application
Cloudflare’s current package workflow uses pywrangler, a Python-oriented wrapper around Wrangler. A project declares its dependencies in pyproject.toml, runs locally with uv run pywrangler dev, and deploys with uv run pywrangler deploy. For a first test, start with one stateless route and one binding rather than the entire application.
Measure startup, CPU time and memory with production-shaped requests. Then add the database or external API path. This sequence exposes runtime and package problems before migration work becomes tangled with storage, authentication and traffic routing.
Python Workers GA is most compelling for small APIs, webhook handlers, edge authentication, request transformation, AI orchestration, RAG endpoints, MCP servers and queue-driven workflows. Traditional containers remain the clearer choice for applications that require a full operating system, broad native-package support, long CPU-bound jobs or mature async SQLAlchemy behavior.
