The news
Cloudflare put Python Workers into general availability on 21 September 2026. The company now describes Python as a fully supported language across its developer platform after a two-year preview.
The release connects Python code directly to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues and Workflows. It also adds supported adapters for FastAPI, Django and Flask applications. A Python Worker can run inside another Worker through Dynamic Workers.
The runtime still starts from Pyodide, which compiles the Python interpreter and supported packages to WebAssembly. Cloudflare has moved more of the boundary work into its runtime and Python software development kit.
Caption: A FastAPI Python Worker saves an upload to R2, places a job on Queues and triggers a Python Workflow that calls Workers AI · Source: Cloudflare, 21 September 2026 · link
Who is bound
The immediate audience is a team that already deploys on Cloudflare and keeps application logic in Python. The change removes a layer of JavaScript conversion code at the platform boundary.
Cloudflare's example shows a Python dictionary sent to a Queue with a regular Python call. During the preview, developers had to convert Python objects into JavaScript objects explicitly. The company says that conversion was a common source of errors for people and coding agents.
Framework users also get a narrower migration path. Cloudflare provides workers.asgi for asynchronous Python web applications such as FastAPI. It provides workers.wsgi for synchronous applications such as Django. The application still runs inside the Workers runtime, so deployment architecture and package compatibility remain part of the decision.
What's new
The important change is the supported interface around the runtime. Cloudflare has added native platform bindings, framework adapters and direct Python access to its storage, messaging and AI services.
That changes the shape of a small service. A FastAPI endpoint can receive a request, write an object to R2 and enqueue follow-up work without a JavaScript bridge. Workflows can coordinate longer jobs. Dynamic Workers can create isolated Python Workers from another Worker.
The announcement also connects Python to Cloudflare's package work. Pyodide supplies a large WebAssembly-ready package base. Cloudflare's tooling resolves supported packages during deployment and includes them with the Worker. Teams should treat the package set as a runtime compatibility surface, because native extensions still depend on what Pyodide and Cloudflare can load.
General availability also changes support expectations. Cloudflare now places Python beside its other first-class Workers languages. That is a product commitment from the platform provider. It remains separate from an application-level reliability claim.
What it does not settle
The announcement gives examples and architectural descriptions. It does not publish a broad performance comparison against TypeScript Workers, containers or other serverless Python runtimes.
Cloudflare also does not claim that every package from the Python Package Index will load. Packages with native extensions need WebAssembly-compatible builds or explicit runtime support. Teams with operating-system dependencies, background processes or long native build chains still need a package audit.
The page shows FastAPI, Django and Flask adapters. It does not replace load tests for a team's own routes, data bindings and cold-start pattern. The release also leaves the commercial question to the normal Workers pricing and limits.
What to do now
Start with one request path that already uses a supported Cloudflare binding. Keep the trial small enough to compare deployment size, startup behavior, tail latency and error handling with the current service.
Before migration:
- List every Python dependency and flag packages with native extensions.
- Verify the required bindings in a staging Worker.
- Exercise ASGI or WSGI behavior under the team's real concurrency pattern.
- Test Queue, R2 and Workflow failure paths, including retries and duplicate delivery.
- Record CPU time, wall time and package size before moving traffic.
A team that already uses TypeScript Workers gains little from a language change alone. The strongest case is a Python service that can remove a separate hosting layer while keeping its framework and platform integrations.