Cloudflare Python Workers are GA, with FastAPI and Django support
Python is now a first-class Workers language, with WSGI and ASGI frameworks, Hyperdrive database drivers, and a cold start Cloudflare puts at about one second.
Python on Workers left beta on September 21. The cold start number is the one that decides fit.
On September 21, 2026, Cloudflare declared Python Workers generally available. The post, by Cloudflare engineer Dominik Picheta, describes Python as a first-class, fully supported language on the developer platform rather than a beta with sharp edges.
What ships: FastAPI, Django, Flask, and anything that speaks WSGI or ASGI. The OpenAI, LangChain and MCP libraries work. Postgres and MySQL connect through Hyperdrive using real drivers, asyncpg and aiomysql, and the usual bindings are available from Python, including Workers AI, R2, D1, Durable Objects, Queues and Workflows. Cloudflare also proposed and got accepted PEP 783, which standardizes the PyEmscripten platform so Python packages can declare WebAssembly support properly instead of being patched per host.
Picheta's framing is that Python developers no longer need to keep the JavaScript runtime in mind: type conversion across the boundary now works without writing any JavaScript.
The number in the comments
The interesting detail is not in the announcement. In the Hacker News thread, Picheta was asked about cold starts and pointed at a previously published figure of about 1.027 seconds, adding that there is still more to do there. Wasmer's Syrus Akbary argued in the same thread that Wasmer Edge hit roughly 60 milliseconds on minimal Python apps against Cloudflare's roughly 900, on 2024 data.
A second caveat came from inside the Python ecosystem. A urllib3 maintainer posting as illia-v noted that the Emscripten backend is explicitly out of scope in that project's security policy, and pointed at CVE-2025-50182, where redirect controls behave unexpectedly when requests route through fetch. That is a real limit and it is not in Cloudflare's post. Python version selection is handled with compatibility flags, python_workers_314 for 3.14, with 3.13 and 3.12 also available, though older selections pull older Pyodide builds without JSPI support.
Why a build studio cares
This site is served by Cloudflare Pages, and a Worker with a Durable Object is what makes our handoff tool work at all, so a new runtime here lands in a stack we already operate. The honest read is that a second of cold start rules out the thing everyone will immediately want to try, which is putting a Python inference or scraping endpoint on the hot path of a page load. What it does unlock is the job that usually ends up on a small always-on box somebody has to keep patched: a background worker, a scheduled data pull, a webhook handler that needs a Python library with no JavaScript equivalent. A one-second start is a perfectly good trade for a machine that runs all day to do something once an hour, and deleting a server is the only migration case worth anything.
Next step: read Cloudflare's announcement, then go find the one Python job in your stack that runs on a machine you would rather not maintain. If you want help deciding whether a one-second cold start is acceptable for it, write to us at hello@gattyworks.com.