Cloudflare says its Python Workers are now generally available, two years after the company first let developers run Python applications on the Workers runtime. The move makes Python a fully supported language on the Cloudflare Developer Platform, alongside TypeScript, rather than an experimental option. For developers who have been waiting to put Python workloads into production on Workers, the practical change is that the runtime, its bindings, and the surrounding tooling are now pitched as production-ready.
The headline capability is native access to Cloudflare's platform services. Python Workers can now connect directly to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, and Workflows without the manual conversion step that previously forced developers to translate Python objects into TypeScript at the RPC boundary. Cloudflare says that conversion is now handled inside the runtime and the Python SDK, so a queue send that once needed glue code using pyodide.ffi can be written as a plain Python dictionary. The company frames this as removing a common source of errors for both people and AI agents writing Python Workers.
Web frameworks are the other major addition. Cloudflare says FastAPI, Django, and Flask applications can now run inside Python Workers through built-in connectors, with the workers.asgi package handling asynchronous frameworks and workers.wsgi covering synchronous ones such as Django. The connectors translate incoming requests into the WSGI or ASGI structures Python applications expect, and Cloudflare says they work with any framework built on those two interfaces, not just the three named. In place of a traditional server like Uvicorn or Gunicorn, the Workers platform itself handles load balancing and scaling, according to the announcement.
Database access gets a fix as well. Python Workers previously could not open TCP sockets, which blocked drivers such as aiomysql and asyncpg from connecting to PostgreSQL or MySQL. Cloudflare says it implemented socket system calls on top of the Workers connect API, translating standard Python socket operations into the JavaScript calls the runtime uses, which is what makes the Hyperdrive integration possible. Developers configure a Hyperdrive binding in Wrangler and then connect with the database drivers they already use.
Package support is the remaining constraint. Because Python Workers run in a WebAssembly sandbox, packages with native C, C++, or Rust extensions must be cross-compiled to WebAssembly first, and Cloudflare says it previously had to compile and host those packages itself, which limited what developers could use. The company says it proposed PEP 783, a standard for running Python in browser runtimes called PyEmscripten, and that the proposal was accepted after more than a year of discussion. Cloudflare says the goal was to let the ecosystem evolve in a way that benefits Pyodide and the wider Python-on-WebAssembly community rather than only its own platform.
The launch lands days after Cloudflare introduced finer-grained access controls that let teams grant a teammate or agent permission to a single Worker instead of broader account resources. Read together, the two announcements point at the same audience: teams putting more automated and agent-written code onto the Developer Platform, where the blast radius of a misconfigured permission or a failed type conversion matters.
Cloudflare's post does not disclose pricing for Python Workers or say whether general availability changes any limits on the runtime. The announcement also does not list which database drivers or native packages are currently supported, pointing readers to separate Hyperdrive documentation for that detail.
