Python Workers are now generally available. The milestone makes Python a first-class, fully supported language on the Cloudflare Developer Platform: existing Python code, libraries and design patterns connect to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows and the rest of the platform. Frameworks such as FastAPI, Django and Flask run inside Python Workers, and a Python Worker can be created inside another Worker with Dynamic Workers.
The choice of Python followed from the runtime's history. Workers has supported WebAssembly since 2018, which provided an environment for a Wasm-compiled Python interpreter; Pyodide gave the team a fast route to broad application support. The goal was the first platform for infinitely scalable Python apps without giving up the ergonomics or performance developers expect elsewhere.
Native bindings without the glue
Previously, Cloudflare bindings required converting Python objects into TypeScript objects explicitly at the RPC boundary — sending a Python dictionary into a Queue, for example, needed glue code. That forced Python developers to keep the JavaScript environment in mind and was a common source of error for humans and AI agents alike.
from pyodide.ffi import to_js
import js
self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))
Type conversion is now handled inside the Workers runtime and the Python SDK, so bindings are usable in a Pythonic way with no JavaScript in the application code.
self.env.QUEUE.send({"key": "value"})
FastAPI, Django and Flask on Workers
A built-in connector lets a Python web application attach to Python Workers. A simple FastAPI app illustrates the pattern:
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
async def root():
message = "Hello, world!"
return {"message": message}
In a native environment, this application would be served by something like uvicorn.
$ uvicorn main:app
On Workers, the same application runs via the workers.asgi package with the addition of one snippet:
from workers import asgi
class Default(WorkerEntrypoint):
async def fetch(self, request):
return await asgi.fetch(app, request, self.env)
# or equivalently
Default = asgi.entrypoint(app)
Synchronous applications such as Django are served the same way through the workers.wsgi package.
from workers import WorkerEntrypoint, wsgi
from your_django_app.wsgi import app
Default = wsgi.entrypoint(app)
The bridge to WSGI and ASGI
Python defines a standard contract between web applications and web servers: the Web Server Gateway Interface (WSGI), or its asynchronous counterpart ASGI. Servers like Uvicorn or Gunicorn normally handle concurrent connections and threads; frameworks like FastAPI concentrate on application logic.
On Workers, the platform is the web server, and the network already handles load balancing and scaling. The workers.asgi and workers.wsgi connectors therefore act as a thin bridge: they translate the incoming native JavaScript request into standard WSGI/ASGI structures and pipe the response back with minimal overhead. The connectors work with any framework implementing WSGI or ASGI, not only FastAPI, Django or Flask. Per-framework guidance lives in the Python Workers documentation.
PostgreSQL and MySQL via Hyperdrive
Relational database support arrived with Hyperdrive integration, which depended on closing a gap: Python Workers previously had no TCP sockets, so database drivers were unusable. Drivers such as aiomysql and asyncpg rely on the standard library's socket module, which makes POSIX system calls. Inside a WebAssembly sandbox those networking syscalls are stubs that always fail.
The fix implements those system calls on top of the Workers connect API. Socket operations are translated into the JavaScript calls used by the runtime at the syscall level, so drivers remain unaware of the underlying implementation. With Hyperdrive configured and the binding set in the Wrangler config, applications connect using familiar drivers.
"hyperdrive": [
{
"binding": "HYPERDRIVE_MYSQL",
"id": "<example id: 57b7076f58be42419276f058a8968187>",
}
]
import aiomysql
from workers import WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
hd = self.env.HYPERDRIVE_MYSQL
conn = await aiomysql.connect(
host=hd.host,
port=int(hd.port),
user=hd.user,
password=hd.password,
db=hd.database,
ssl=None,
)
cur = await conn.cursor()
await cur.execute("SELECT username FROM user")
r = await cur.fetchall()
await cur.close()
conn.close()
The Hyperdrive Python Workers documentation lists supported packages.
Growing the WebAssembly packaging ecosystem
Packages with native C/C++/Rust extensions must be cross-compiled to WebAssembly, and no standard route for doing so previously existed — the team compiled and hosted custom Wasm packages manually, which capped how many packages worked. Rather than build packages useful only to Python Workers, the team targeted the underlying Pyodide ecosystem and proposed PEP 783, which standardizes PyEmscripten as a platform for running Python in browser runtimes. It was accepted after more than a year of discussion, letting maintainers publish packages for the platform across all environments that implement it.
The Pyodide build toolchain was stabilized and made accessible to maintainers, and PyEmscripten platform support was added to cibuildwheel. Ecosystem adoption is ongoing; the team is working with major maintainers on PyEmscripten builds and invites reports of unsupported packages via Discord or GitHub. The EuroPython 2026 talk “Python Everywhere: The State of Python on WebAssembly” covers how this was achieved.
AI agents and pipelines
Data science and machine learning packages make Python a natural fit for agents and AI pipelines, but libraries such as openai and langchain depend on HTTP clients like requests and httpx, which did not work properly without low-level socket support. The team contributed upstream so these clients can route requests through the JavaScript fetch API in WebAssembly environments. Together with the socket work, the full networking stack now functions in Python Workers.
Libraries including openai, langchain and mcp therefore run natively, alongside Workers AI for serverless GPU inference on Cloudflare's network or Cloudflare AI Gateway as a proxy. The example below runs Workers AI models in langchain through the langchain-cloudflare package:
from langchain_cloudflare import ChatCloudflareWorkersAI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import PromptTemplate
from workers import Response, WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
prompt = PromptTemplate.from_template(
"In one sentence, describe a great day in the life of an {profession}."
)
llm = ChatCloudflareWorkersAI(
model_name="@cf/meta/llama-3.3-70b-instruct-fp8-fast",
binding=self.env.AI,
max_tokens=64,
)
chain = prompt | llm | StrOutputParser()
result = await chain.ainvoke({"profession": "electrician"})
return Response.json({"result": result})
Production-ready patterns
The python-workers-examples repository collects patterns combining Python Workers with the Cloudflare ecosystem.
An AI-driven image-to-image generator accepts user requests, places them in a Queue and uses Workflows to orchestrate generation via Workers AI, storing results in an R2 bucket.
A Python Worker connects to the ATProto/Bluesky Jetstream WebSocket and, backed by a Durable Object, maintains long-lived state so the connection stays alive — avoiding a dedicated server for a real-time event firehose.
Additional examples
- An MCP server built with the official Python MCP package, giving AI assistants access to edge data.
- A RAG system using Workers AI and Vectorize, Cloudflare's vector database.
The developer documentation now carries Python example code across Cloudflare products: wherever a TypeScript example exists, a Python example generally does too, and snippets can be toggled between JavaScript, TypeScript and Python.
General availability is a milestone, not an endpoint. Work continues on two fronts: making Python Workers faster and less memory-hungry, and widening the set of packages they can run.
Feedback from developers building on the runtime shapes what gets prioritized next. The Python Workers documentation is the place to start for those writing their first Worker.
