Cloudflare Python Workers Reach GA: Real Python, No Threads

Cloudflare has taken Python Workers out of preview: after two years in beta, the company now calls Python "a first-class, fully supported language on the Cloudflare Developer Platform." That's a meaningful claim for a serverless platform historically built around JavaScript and WebAssembly — and the way it's implemented is worth understanding before you reach for it.

How it actually runs

This isn't a Python-flavored DSL bolted onto V8. Cloudflare compiles real CPython to WebAssembly using Pyodide, then executes it inside workerd, the same V8-based runtime that powers every other Worker. Local development mirrors this exactly: the pywrangler CLI (shipped on PyPI as workers-py) runs the identical Pyodide-in-WebAssembly-in-V8 stack on your machine, distributed as a roughly 123MB workerd binary. That's a deliberate design choice — if it behaves in dev, it should behave the same way in production, because it's literally the same execution path.

The catch: no threads, no multiprocessing

The WebAssembly sandbox Python runs in disables both multiprocessing and threading. Cloudflare documents the full set of stdlib gaps, but this is the headline limitation: any Python code that assumes it can spin up a thread pool or fork worker processes will not work as written. For request-scoped, I/O-bound logic — parsing webhooks, calling APIs, transforming JSON — that's rarely a problem, since Workers already lean on async I/O rather than OS-level concurrency. For CPU-bound batch work or anything ported from a traditional multiprocessing-based Python service, it's a hard rewrite requirement, not a tuning knob.

Why builders should care

The interesting part isn't "Cloudflare added a language" — it's that Python now has a genuinely production-grade path to the edge, with a local dev loop that doesn't lie to you about what will happen in prod. That matters for teams building lightweight AI-agent backends, webhook handlers, or data-shaping services in Python who previously had to either rewrite in JavaScript or run a separate always-on server just to get edge deployment. It doesn't replace a real compute layer for anything threaded or CPU-heavy, but for the glue-code tier of an agentic or fintech stack — the part that receives an event, calls a model or an API, and returns a response — it's now a legitimate, low-ops deploy target.

The takeaway

Treat Python Workers as what they are: full CPython, real stdlib compatibility for the common case, running single-threaded in a WASM sandbox. If your workload is async-shaped, this GA is good news. If it leans on threading or multiprocessing, budget time to restructure before you migrate — the limitation is architectural, not a bug that will get patched away.