Cloudflare Python Workers just went GA — here's what Pyodide in workerd means for edge deployment
After two years in preview, Cloudflare's Python Workers are production-ready. They're running Pyodide compiled to WASM in the V8-based workerd runtime, which changes the shape of what you can deploy at the edge.
Cloudflare announced Python Workers GA yesterday. After two years in preview, Python is now a first-class language on the Cloudflare Developer Platform. You can deploy FastAPI, Flask, or Django apps to the edge without touching JavaScript.
The stack is unusual. Cloudflare compiles Python to WebAssembly via Pyodide and runs it inside their V8-based workerd runtime. That's a different shape than most edge compute offerings, which either run native binaries or JavaScript exclusively.
What workerd actually is
workerd is Cloudflare's open-source runtime for Workers. It's built on V8 (the JavaScript engine from Chrome) and designed for multi-tenant isolation. The runtime itself is available at github.com/cloudflare/workerd.
Pyodide is the CPython interpreter compiled to WebAssembly. It runs inside the V8 sandbox. This means Python code has the same startup characteristics as JavaScript Workers — cold start is sub-5ms in most regions.
The limitation is that not all Python packages work. Anything with C extensions needs to be compiled to WASM. Cloudflare ships a set of pre-compiled packages (NumPy, pandas, scikit-learn, Pillow) but the long tail isn't available yet.
What you can deploy
Cloudflare's announcement focuses on web frameworks (FastAPI, Flask, Django) and AI orchestration libraries (LangChain, LlamaIndex). The latter is the real use case — you can now run agentic workflows at the edge without a Node.js wrapper.
The integrations are native. You call D1 (Cloudflare's SQLite service), R2 (object storage), and Workers AI directly from Python without glue code. The Cloudflare SDK exposes those APIs as Python objects.
For us, this changes what we can ship to clients who need <50ms latency. We've been deploying voice agent backends to Cloudflare Workers for 18 months, but they've all been TypeScript. Python Workers means we can use LangGraph or the Anthropic SDK directly instead of maintaining a JavaScript port.
The WASM trade-off
Running Python as WASM inside V8 is a constraint and an advantage. The constraint: package compatibility. If your code depends on a C extension that hasn't been compiled to WASM, it won't run.
The advantage: isolation. Every request runs in a fresh V8 isolate with its own memory. There's no shared state between requests unless you explicitly use Durable Objects. This is safer than a traditional Python server where one bad request can crash the process.
The startup time is real. Cloudflare's benchmarks show Python Workers cold-starting in 4-6ms, which matches JavaScript Workers. That's 10× faster than spinning up a container.
Where this fits in our stack
We deploy voice agents on three platforms: Retell (hosted), ElevenLabs (hosted), and Twilio + Cloudflare Workers (self-hosted). The last one is for clients who need <100ms response time or who can't send PII to third-party APIs.
Until now, those Cloudflare Workers have been TypeScript calling the OpenAI or Anthropic APIs directly. Python Workers means we can use LangGraph for multi-step workflows without rewriting it in JavaScript. We still need to verify that the Anthropic SDK and LangGraph both work in Pyodide, but the path is clear.
The other use case is internal tooling. We run a multi-tenant CRM on Cloudflare Workers that handles API routing for 7 clients. It's TypeScript today. Python Workers would let us use FastAPI instead, which is what most of our team writes locally.
What doesn't work yet
Cloudflare's docs list several limitations. You can't use subprocess, threading, or asyncio.run_in_executor. File I/O is restricted — you can read from a virtual filesystem but you can't write to disk. Network access is limited to fetch and WebSocket.
These constraints rule out some patterns. If your code spawns background threads or writes to /tmp, it won't run. If you depend on a package that hasn't been compiled to WASM, you'll need a fallback.
The biggest gap is the package ecosystem. Cloudflare ships ~50 packages pre-compiled, but the Python Package Index has 500,000. Most of those won't work without manual porting.
Why this matters
Cloudflare is the first major edge platform to ship Python as a first-class language. Vercel Edge Functions and AWS Lambda@Edge both require JavaScript. Fastly Compute@Edge supports Rust and JavaScript but not Python.
This opens edge deployment to teams who don't write JavaScript. Most ML engineers write Python. Most data teams write Python. Most AI orchestration libraries are Python-first. Python Workers means those teams can deploy to the edge without learning a new language.
For us, it means we can consolidate the stack. We've been maintaining parallel implementations — TypeScript for Cloudflare, Python for everything else. Python Workers collapses that split.
The WASM constraint is real but manageable. If your code depends on a niche C extension, you'll still need a traditional server. For everything else, the edge is now an option.