When you take stock of the jobs running in-house, a good number of them turn out to be written in Python: daily aggregation, data integration with external services, preprocessing for machine learning. It is not unusual for the person who wrote them to have left the company.
Even if you try to move them to a serverless runtime, if that runtime assumes JavaScript, you end up inserting a thin translation layer to call the Python code, and maintaining that layer becomes new debt. That assumption has now changed.
What changed with general availability
On September 21, 2026, Cloudflare announced that Python Workers are generally available. Cloudflare positions Python as a first-class, fully supported language on its developer platform.
The changes that matter in practice are the following.
FastAPI, Django and Flask applications run through built-in connectors. workers.asgi handles asynchronous frameworks, and workers.wsgi handles synchronous ones such as Django. This means you may be able to bring existing web apps over as they are.
You can access Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues and Workflows directly from Python. The manual conversion that was previously required is no longer needed.
Libraries such as openai, langchain and mcp now work, thanks to upstream fixes that let HTTP clients communicate through the fetch API.
For development and deployment you use pywrangler: pywrangler dev to check locally, and pywrangler deploy to deploy.
Packages that don't run have something in common
This is what you should check before estimating.
Python Workers run Pyodide, which is CPython compiled to WebAssembly, inside a V8 isolate. This structure determines which packages can be used.
| Type | Handling |
|---|---|
| Pure Python packages and PyEmscripten packages | Can be used from PyPI |
| Packages bundled with Pyodide (such as numpy, pandas and cryptography) | Available |
| Packages with C, C++ or Rust native extensions that fit neither of the above | Cannot be used until a Wasm wheel is released |
Even libraries with native extensions, such as numpy, pandas and cryptography, are within the supported range if they are bundled with Pyodide. The third category is where you get stuck. Cloudflare itself explains that WebAssembly support for packages is still at an early stage and that some packages do not yet have PyEmscripten wheels on PyPI. This is the gap between "Python runs" and "your own code runs".
To speed up startup, an optimization is built into deployment. Module-level imports and initialization run at deploy time, and the resulting Wasm memory state is saved as a memory snapshot. The initialization work an isolate would otherwise do when it starts is completed in advance.
Triage to do before estimating
Whether code can be moved depends first on its dependencies, not on how many lines it has. There are two tasks.
- Export the list of dependency packages from
requirements.txtorpyproject.toml - Among them, count the ones that include native extensions, are not bundled with Pyodide, and have no Wasm wheel on PyPI either
If the count is zero, it is worth moving ahead with evaluating the move. If even one remains, the next question is "Does that processing really need to run on this platform?" Keeping the affected processing somewhere else and moving only the API entry point can be a realistic way to split it.
Besides dependencies, also check the limits of the standard library. According to the official documentation, threading and multiprocessing can be imported but do not work. File reads and writes go to a temporary in-memory area, and its contents are lost when the isolate is destroyed. Aggregation jobs that run in parallel with threads, and integration jobs that write a file and read it back later, need to be reworked.
The same kind of triage works whenever you are choosing a runtime platform. We set out the criteria in choosing and migrating between Cloudflare and AWS.
Estimating beyond "it runs"
If your Python code is old, version issues stand in the way before any move: Python 2 code is still around, or even Python 3 code relies on outdated idioms. In that case, the effort to upgrade the language version comes before any discussion of the runtime platform. We wrote about how to build that estimate in estimating a Python 2 to 3 migration.
If you ask an outside party to do the move, the first thing to hand over is the list of dependency packages. With it, they can more easily gauge whether the move is feasible. If you only say "we want to move our Python jobs" without it, the investigation itself becomes a line item in the estimate.
We checked Cloudflare's blog post dated September 21, 2026, the Python Workers documentation (overview, packages, how Python Workers work, and the standard library) and Pyodide's list of bundled packages on September 25, 2026. We have not deployed to Python Workers, tested FastAPI or Django applications, checked whether individual packages can be imported, or measured startup time. The range of supported packages changes, so check the official documentation before adopting it. This article organizes the conditions of use and the triage to do before estimating.
For assessing whether your existing Python code can be moved, or for choosing a runtime platform, please consult GleamHub.
