#568: Cloudflare Python Workers

Summary of #568: Cloudflare Python Workers

by Michael Kennedy

1h 2m•November 3, 2026

Overview of #568: Cloudflare Python Workers

In this episode of Talk Python To Me, Michael Kennedy speaks with Cloudflare engineers Dominic Pichetta and Jay Choi, plus Hood Chatham (a Pyodide maintainer), about the launch of Cloudflare Python Workers. The discussion explains how Python can now run on Cloudflare’s edge network using CPython compiled to WebAssembly inside V8, enabling Python apps to run close to users across Cloudflare’s global points of presence. The episode also covers the broader state of Python on WebAssembly, packaging challenges, memory snapshots, and how Cloudflare’s platform services fit into the story.

What Cloudflare Python Workers Are

Cloudflare Python Workers let you deploy Python code as edge workers without manually building WebAssembly artifacts yourself.

  • Your Python app ships as files, not a traditional server container.
  • Cloudflare runs the code on the edge in a runtime built around:
    • CPython
    • WebAssembly
    • V8
    • Pyodide / Emscripten-based tooling
  • The goal is low-latency execution near users across Cloudflare’s global network.
  • It’s especially well-suited for API servers and other I/O-heavy workloads.

Main Themes and Technical Takeaways

Python on WebAssembly is maturing

The guests describe the broader Python-on-WASM ecosystem as much more stable than it was a few years ago.

  • Pyodide is increasingly polished and reliable.
  • CPython support for Emscripten exists upstream as a tier-3 platform.
  • The ecosystem is moving toward more official support and better packaging standards.
  • The team is trying to make WebAssembly a more first-class Python deployment target.

Packaging was the biggest hurdle

A major topic was the packaging story, especially for scientific Python libraries.

  • Pure-Python packages are relatively easy.
  • Packages with C/C++/Rust extensions need to be cross-compiled to WebAssembly.
  • Cloudflare and Pyodide previously had to build many packages themselves, which was slow and brittle.
  • New packaging support now lets maintainers build WebAssembly/Pyodide wheels in their own CI pipelines.
  • This shifts the burden from Pyodide maintainers to package maintainers, which is much more scalable.

Socket support unlocked more of the platform

One of the biggest enablers for Python Workers was support for sockets, which allowed integration with Cloudflare services like Hyperdrive.

  • Browsers don’t normally expose raw socket access.
  • Cloudflare wired socket APIs into the runtime so Python code can interact with databases and other network services.
  • This makes it possible to support more realistic backend workloads, not just browser-like demos.

Memory snapshots improve startup time

The team also discussed memory snapshots, which help reduce cold start overhead.

  • The idea is to avoid redoing expensive startup and import work on every invocation.
  • This is especially important for edge workers where fast startup matters.
  • Implementing snapshots in Python is tricky because Python does not have a native “compile time vs runtime” distinction.
  • The discussion connected this idea to partial evaluation and to future language/runtime research.

Cloudflare Platform Building Blocks Mentioned

The episode also walked through the Cloudflare services that Python Workers can use.

D1

  • Cloudflare’s SQLite-based distributed database.
  • Designed to feel like local SQLite, but replicated and available at the edge.
  • Good fit for lightweight relational workloads.

Hyperdrive

  • A database acceleration/proxy layer for external databases like PostgreSQL and MySQL.
  • Helps reduce latency by keeping connections closer to the edge.
  • Particularly useful once socket support is available.

R2

  • Object storage similar to S3, but with Cloudflare’s model and no egress fees.
  • Useful for blobs, files, and large assets.

Queues, AI, and other services

  • Workers can also connect to Cloudflare queues, AI inference, and other developer-platform features.
  • The idea is to build full-stack apps entirely within Cloudflare’s ecosystem.

Deployment and Local Development

Deployment model

  • You don’t manually ship WebAssembly.
  • You write Python, add dependencies, and deploy through Cloudflare tooling.
  • Package installs are handled via UV/PyWrangler-style workflows for supported WebAssembly packages.

Local testing

  • Cloudflare’s runtime is open source as workerd.
  • You can run the same runtime locally for development.
  • This helps close the gap between local testing and production behavior.

What Kind of Apps Fit Best

The guests were clear that Python Workers are not meant for everything.

Best fit

  • API servers
  • I/O-heavy applications
  • Business logic close to users
  • Small web apps that benefit from global distribution
  • Hobby projects and lightweight services

Not ideal

  • Heavy data science workloads
  • Large in-memory analytics jobs
  • GPU/SIMD-heavy computation
  • Long-running compute-intensive tasks

Data work is possible, but with limits

  • Smaller pandas/parquet-style tasks may work.
  • The platform is memory-constrained, so streaming and incremental processing are preferred.
  • Tools like Polars are often a better fit than large in-memory pandas workflows.

Limitations and Practical Constraints

A few important constraints came up repeatedly:

  • Memory limit: 128 MB
  • CPU limits: tight for free-tier workloads
  • Free tier: generous, including a high daily request allowance
  • Many libraries assume a full OS environment, which does not exist in the same way on Workers.
  • Threading, multiprocessing, and some socket behavior can still be problematic depending on the runtime.

Notable Insights

  • “Pyodide is putting Python in the browser; Cloudflare is putting the browser in the server.”
    • This was one of the episode’s best conceptual explanations.
  • Python Workers are effectively a way to bring Python into the edge without giving up the Cloudflare platform.
  • The packaging work is as important as the runtime itself.
  • A major theme was making Python fit into a distributed, low-latency, serverless edge environment without forcing developers to learn a totally new model.

Recommendations and Next Steps

If you’re curious about trying it:

  • Start with a small I/O-bound API.
  • Use the existing Python web framework adapters, especially if you already know FastAPI, Flask, or Django-style patterns.
  • Keep workloads lightweight and memory-conscious.
  • Explore Cloudflare’s local development tooling and docs.
  • If something doesn’t work, the guests encouraged people to report issues and contribute back.

Final Takeaway

This episode shows that Python on the edge is no longer just a novelty. With Cloudflare Python Workers, Python can now run as a real production option on a global edge network, backed by WebAssembly, better packaging support, and a growing set of platform services. It’s especially compelling for developers who want low-latency APIs and global distribution without managing traditional infrastructure.