Cloudflare Python Workers GA: FastAPI and Django at the edge

Cloudflare Python Workers are now generally available, and the headline is not the language: it is that FastAPI, Django and Flask run without uvicorn or Gunicorn, because the Workers platform itself is the web server. Cloudflare announced GA on 21 September 2026. This post covers what GA changed, the limits Cloudflare documents, and when Python at the edge beats a container or Lambda.

If you are weighing a Python API on Workers, the limits section is the part to read twice. Most of them come from one fact: your code runs on Pyodide, CPython compiled to WebAssembly, inside a V8 isolate.

What GA changes for Cloudflare Python Workers

Cloudflare says GA means Python is now a first-class, fully supported language on its developer platform. Python Workers first appeared two years earlier. The practical changes, as of September 2026:

Change	What it means
Native bindings	No more manual to_js conversion; self.env.QUEUE.send({"key": "value"}) just works
Web frameworks	workers.asgi and workers.wsgi connectors for FastAPI, Django, Flask and other ASGI/WSGI apps
Databases	TCP socket support, so PostgreSQL and MySQL drivers work through Hyperdrive
HTTP clients	Libraries built on requests or httpx, including openai, langchain and mcp, now run
Packages	PyEmscripten wheels from PyPI, after PEP 783 was accepted

The bindings cover Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues and Workflows. That is the real pitch: FastAPI plus Workers bindings adds up to Python at the edge with storage, queues and inference reachable from the same Python code, without JavaScript glue.

AI libraries and the examples Cloudflare ships

The networking fixes matter most for AI work. Libraries like openai and langchain depend on HTTP clients that previously didn't work properly in Python Workers; Cloudflare contributed upstream so they route through the JavaScript fetch API. Its examples repository includes an image generator that takes a request, puts it on a Queue, orchestrates generation with Workflows and Workers AI, and stores the result in R2, plus a Durable Object that keeps a long-lived WebSocket to the Bluesky Jetstream open.

Those examples show the intended shape: short Python handlers stitched together by platform services, with state held in Durable Objects, D1 or R2 rather than in the process. If your service already looks like that, the move is small. If it is a monolith with a warm in-process cache, it is not.

Deploy FastAPI on Cloudflare Workers: what the code looks like

A FastAPI app needs one extra line. You import the connector and set Default = asgi.entrypoint(app); Django uses the WSGI or ASGI adaptor, with Cloudflare noting Python Workers are optimised for ASGI. Bindings reach your routes through request.scope["env"].

Cloudflare explains why there is no server process: the connectors translate the incoming JavaScript request into standard ASGI or WSGI structures and pipe the response back. You add the python_workers compatibility flag, manage dependencies in pyproject.toml, and use pywrangler, a wrapper around wrangler that bundles your packages on deploy.

Cold starts get handled at deploy time. Cloudflare executes your entrypoint and its top-level imports, snapshots the WebAssembly memory and ships that snapshot, so requests boot from it instead of re-running initialisation.

Cloudflare Python Workers limits, as documented

These are the constraints Cloudflare publishes. We quote them as written rather than paraphrase.

Platform limits that bite Python first

Limit	Workers Free	Workers Paid
CPU time per HTTP request	10 ms	5 min (default: 30 seconds)
Memory per isolate	128 MB	128 MB
Worker size	64 MiB	64 MiB
Worker startup time	1 second	1 second

The limits page says the 128 MB covers "the JavaScript heap and WebAssembly allocations", and applies per isolate, not per invocation. Because Python Workers run the interpreter as WebAssembly, the interpreter shares that budget with your app and every request the isolate is serving.

Standard library gaps

The full standard library is available with exceptions. Modules not available include curses, dbm, ensurepip, fcntl, grp, idlelib, lib2to3, msvcrt, pwd, resource, syslog, termios, tkinter, turtle.py, turtledemo, venv, winreg and winsound. multiprocessing and threading "can be imported, but are not functional due to the limitations of the WebAssembly VM". pty and tty cannot be imported. The filesystem is in-memory and ephemeral: data is "lost when the Worker isolate is destroyed".

Python packages on Cloudflare Workers

Python Workers support pure Python and PyEmscripten packages on PyPI, plus packages included in Pyodide. Cloudflare's own wording: "WebAssembly support for Python packages is still in early stages, and some packages may not yet be available as PyEmscripten wheels." Anything with C, C++ or Rust extensions needs a PyEmscripten build before it will run.

Versions and compatibility dates

Your Pyodide version is chosen by your compatibility date. Hyperdrive in Python Workers needs a compatibility date of 2026-09-08 or later, and Cloudflare lists tested drivers: asyncpg, pg8000 and psycopg for PostgreSQL, aiomysql and pymysql for MySQL. Python versions past their five-year support window keep running but get no patches.

Python Workers vs Lambda and containers

Edge Python wins when the work is I/O-bound and latency-sensitive: an API that reads D1 or R2, calls Workers AI, drops jobs on a Queue, or fronts a database through Hyperdrive. CPU time does not include waiting on network calls, per the limits page, so a request that mostly awaits I/O fits the model well. You also skip the server config entirely.

It loses when the work needs threads or processes, a native-extension package without a WebAssembly wheel, a large in-memory dataset, or a persistent local filesystem. A container, or Lambda running standard CPython, installs ordinary compiled wheels and is not bound by the Workers 128 MB isolate limit. Lambda has its own ceilings, which we looked at in the AWS Lambda timeout conditions.

The strongest case against moving now: Cloudflare itself lists "more performant and memory efficient" and supporting more packages as the next work, which tells you where the gaps are. The case for: GA means supported, and a thin FastAPI API on bindings is low-risk to try.

Is Cloudflare Python Workers production ready?

For the right workload, yes: Cloudflare now supports it as a first-class language. Before you commit, audit your dependency list against PyPI for WebAssembly wheels, load-test memory with realistic concurrency, and read the Cloudflare Workers production issues teams hit on the JavaScript side, since most of them are platform-level and apply equally to Python.

If you are deciding between Workers, Lambda and containers for a Python service, our serverless architecture team can run that comparison on your actual dependency list, and our API development team builds the FastAPI side. The first check is the cheapest: run pywrangler dev against your pyproject.toml and see what fails to install.