Cloudflare Announces General Availability of Python Workers

Cloudflare Announces General Availability of Python Workers Cloudflare has made Python Workers generally available, turning Python into a fully supported language across the Cloudflare Developer Platform. Built on WebAssembly via Pyodide, the release features native platform bindings, WSGI and ASGI web framework adapters, system-call level socket support for relational databases, upstream networking fixes for AI libraries, and contributions toward standardized WebAssembly package builds. Python Workers reached General Availability, integrating natively with Cloudflare Developer Platform bindings without requiring manual JavaScript type conversions. Built-in connectors (workers.asgi and workers.wsgi) allow frameworks like FastAPI, Django, and Flask to run serverlessly while Cloudflare handles scaling and load balancing. Workers now implements TCP socket system calls via the Workers connect API, enabling relational database drivers and Hyperdrive connections from within WebAssembly. Cloudflare proposed the accepted PEP 783 (PyEmscripten) and updated build tools like cibuildwheel to standardize cross-compiling Python packages with native extensions for WebAssembly. Upstream networking changes allow HTTP clients such as requests and httpx to route through the JavaScript fetch API, unlocking native execution for AI libraries like openai and langchain. Platform Bindings and Framework Bridges Previously, invoking Cloudflare Developer Platform bindings from Python Workers required explicit type conversion glue code between Python and TypeScript. The runtime and Python SDK now encapsulate this conversion process entirely. Additionally, Cloudflare introduced workers.asgi and workers.wsgi connectors that act as lightweight bridges between incoming JavaScript requests and standard Python server interfaces. Instead of requiring web servers like Uvicorn or Gunicorn, the Workers infrastructure directly manages concurrency, load balancing, and scaling for frameworks such as FastAPI, Flask, and Django. TCP Sockets and Hyperdrive Database Integration Because Python Workers run inside a WebAssembly sandbox where standard POSIX networking calls fail, database drivers previously could not open TCP sockets. Cloudflare resolved this by intercepting low-level Python socket module operations and translating them into the Workers connect API at the system call level. This enables async and sync database drivers—such as asyncpg and aiomysql—to connect directly through Hyperdrive to databases like PostgreSQL and MySQL without driver modifications. WebAssembly Packaging and PEP 783 Running packages with C, C++, or Rust extensions in Workers requires WebAssembly cross-compilation. Rather than relying solely on proprietary, manually maintained builds, Cloudflare authored PEP 783, which established the accepted PyEmscripten standard for running Python in browser runtimes. Cloudflare also added PyEmscripten support to cibuildwheel and refined the Pyodide build toolchain to help upstream package maintainers publish compatible wheels. Networking Enhancements for AI Libraries AI and data science tooling commonly relies on HTTP clients like requests and httpx to reach external endpoints. Cloudflare contributed upstream fixes enabling these clients to route network requests through the JavaScript fetch API in WebAssembly environments. Alongside low-level socket support, this change permits libraries such as openai, langchain, and mcp to operate directly inside Workers, allowing developers to orchestrate pipelines across Workers AI, Vectorize, and R2 storage.

Cloudflare 宣布 Python Workers 正式商用（GA） Cloudflare 宣布 Python Workers 现已正式商用（GA），成为 Cloudflare 开发者平台的一等公民语言。基于 WebAssembly 和 Pyodide，开发者可在无服务器边缘环境中运行 FastAPI、Django 等常见 Python 框架及主流 AI 库，并无缝集成 Cloudflare 旗下各类产品服务。 Python 成为 Cloudflare 平台原生支持语言，SDK 和运行时自动封装类型转换，无需编写 JS 粘合代码即可调用平台绑定。 推出 workers.asgi 与 workers.wsgi 连接器，直接将原生 JS 请求桥接至 WSGI/ASGI 应用，无需自建传统 Web 服务器。 通过 Workers connect API 在系统调用层实现 Socket 桥接，解决 Wasm 沙箱限制，使 aiomysql、asyncpg 及 Hyperdrive 数据库集成可用。 推动并获批 PEP 783（PyEmscripten 平台标准），完善 Pyodide 工具链并在 cibuildwheel 中加入支持，加速 C 扩展包向 Wasm 跨平台编译。 原生平台绑定与 Web 框架兼容 此前在 Python Workers 中调用 Cloudflare 绑定需要手动进行 Python 与 TypeScript 对象转换。如今运行时与 Python SDK 内置了自动类型封装，开发者可直接以原生 Python 语法与 R2、D1、Queues 等服务交互。同时，官方提供了 workers.asgi 与 workers.wsgi 轻量桥接包，将 JavaScript 请求直接转为标准 WSGI/ASGI 结构，支持 FastAPI、Flask、Django 等框架利用 Cloudflare 全球网络自动扩展，无需配置 Uvicorn 等服务器。 底层 Socket 桥接与关系型数据库支持 针对 WebAssembly 沙箱内 POSIX 网络系统调用失效、导致 Python 数据库驱动无法运行的问题，Cloudflare 利用 Workers connect API 在底层重写了 Socket 系统调用。驱动发起的网络操作会被转译为 Workers 运行时的 JavaScript 调用，从而无缝解锁 aiomysql、asyncpg 等驱动，并支持通过 Hyperdrive 连接 PostgreSQL 和 MySQL。 推动 Wasm 打包生态标准与 AI 应用落地 为解决原生 C/C++/Rust 扩展跨编译困难的问题，Cloudflare 推动了 PEP 783（PyEmscripten 平台）的通过，并向 cibuildwheel 添加支持以协助维护者发布 Wasm 格式 wheel 包。此外，团队向上游改进了 HTTP 客户端使其对接 JS fetch API，解决了 requests 和 httpx 的限制，使开发者能在边缘原生运行 openai、langchain 与 MCP 服务，配合 Workers AI 和 Vectorize 构建检索增强生成（RAG）及 AI 流水线。

We introduced Python Workers two years ago, providing a way to [run Python applications](https://blog.cloudflare.com/python-workers/) in the Cloudflare Workers runtime. Our goal was to make it as simple to write Workers in Python as it is in TypeScript, and to make the ecosystem of Python packages and frameworks “just work”. Today, Python Workers are now generally available (GA). What does GA mean? It means Python is now a first-class, fully supported language on the Cloudflare Developer Platform. You can bring the Python code, libraries, and design patterns you already know and connect them seamlessly to Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows, and the rest of the Cloudflare platform. You can also run popular Python frameworks like FastAPI, Django, and Flask inside Python Workers. You can even create a Python Worker inside another Worker using [Dynamic Workers](https://blog.cloudflare.com/dynamic-workers/). Bringing Python to Cloudflare Workers was a natural choice. Because Workers has supported [WebAssembly since 2018](https://blog.cloudflare.com/webassembly-on-cloudflare-workers/), it gave us the perfect environment to run a Wasm-compiled Python interpreter. By using [Pyodide](https://pyodide.org/en/stable/), we were able to quickly support a wide range of Python applications in Cloudflare Workers. Our goal was to create the first platform for infinitely scalable Python apps, while making it as easy and performant as developing Python apps anywhere else. The features we are highlighting today are the result of this multi-year effort. Many developers are already building applications within Python Workers; today, we are making these capabilities production-ready for everyone. Python Workers now natively support Cloudflare Developer Platform bindings. Previously, using these Cloudflare bindings in Python Workers required converting Python objects into TypeScript objects explicitly at the RPC boundary. For example, sending a Python dictionary into a Cloudflare Queue required the following glue code to work: This required Python developers to keep the JavaScript environment and code in mind while writing Python Workers, and it was a common source of error for both humans and AI agents. To address this, we have [encapsulated the entire type conversion process](https://blog.cloudflare.com/python-workers-rpc/) within the Workers runtime and the Python SDK. This allows you to utilize all Cloudflare bindings in a Pythonic way without writing a single line of JavaScript code, making the following just work: You can now run your favorite Python framework, such as FastAPI, Django, or Flask, to build an API server in Python Workers. We implemented a built-in connector that you can use to easily connect your web application to Python Workers. Let’s say you have a simple FastAPI web application: In native environments, you would use a web server such as `uvicorn` to run this application. In Python Workers, you can run the same application using the workers.asgi package we provide, just by adding this snippet to your code: Similarly, you can use `workers.wsgi` package to run synchronous web applications such as Django. Python has a standard contract for how web applications should communicate with web servers, known as the Web Server Gateway Interface (WSGI), or its modern asynchronous counterpart, ASGI. This standard allows developers to build applications that are completely server-agnostic. In a traditional deployment, web servers like Uvicorn or Gunicorn are responsible for handling multiple concurrent client connections and threads to scale traffic, while web frameworks like FastAPI can focus purely on the application logic. In Cloudflare Workers, the Workers platform itself serves as the web server. Since our global network already seamlessly handles load balancing and infinite scaling, we don't need to reinvent the wheel by running a server inside Python Workers. Instead, our `workers.asgi` and `workers.wsgi` connectors act as a thin, optimized bridge. They translate the incoming native JavaScript request into the standard WSGI/ASGI structures that Python applications expect, and seamlessly pipe the response back out with minimal overhead. By doing this, Python developers get the best of both worlds: you can write and organize code using your favorite web frameworks, while letting the Cloudflare Workers platform instantly scale your API across the globe, without ever configuring a server. These connectors can be used not only with FastAPI, Django, or Flask, but with any Python web framework that uses the [WSGI](https://peps.python.org/pep-3333/) or [ASGI](https://asgi.readthedocs.io/en/latest/) interface. You can find more information about using each web framework in the [Python Workers documentation](https://developers.cloudflare.com/workers/languages/python/packages/). If you are building a Python application using relational databases such as PostgreSQL or MySQL, you can now integrate [Hyperdrive](https://developers.cloudflare.com/hyperdrive/) into Python Workers. Previously, Python Workers didn’t support TCP sockets, making database drivers unavailable. To understand why this was a blocker, you need to look at how WebAssembly operates. Python database drivers like `aiomysql` or `asyncpg` rely on the standard library's `socket` module to establish connections. In a standard environment, this module makes POSIX system calls to the underlying operating system. Inside a WebAssembly sandbox, those POSIX networking syscalls are normally stubs that always fail. Any attempt to open a standard socket would immediately fail. To solve this problem, we implemented socket system calls using the Workers [connect](https://developers.cloudflare.com/workers/runtime-apis/tcp-sockets/) API. When a database driver attempts to open a TCP connection, it goes through our custom socket syscall implementation. It translates standard Python socket operations like opening a connection and reading bytes into the corresponding JavaScript calls used by the Workers runtime. Because this translation happens at the system call level, your database drivers don't have to know about the underlying implementation at all. This socket bridge is what makes our Hyperdrive integration possible. To use Hyperdrive in Python Workers, first connect your database with Hyperdrive and set up the binding in the Wrangler config: Then, connect to Hyperdrive using the database drivers you are familiar with: You can refer to the [Hyperdrive Python Workers documentation](https://developers.cloudflare.com/hyperdrive/examples/python-workers/) to find out how you can use Hyperdrive in Python Workers, and which packages are currently supported. Because Python Workers run inside a WebAssembly sandbox, any packages with native C/C++/Rust extensions must be cross-compiled to WebAssembly to run in Python Workers. However, previously, there was no standard way to cross-compile any Python packages to WebAssembly. That meant our team had to manually compile and host custom WebAssembly packages. This greatly limited the number of packages you could actually use in Python Workers. We wanted to fix this and allow users to use a wider variety of packages. However, we didn’t want to merely build packages usable only in Python Workers, which wouldn’t benefit the community. Since Python Workers are built on top of Pyodide, we wanted the ecosystem to evolve in a way that benefits Pyodide and the entire Python-on-WebAssembly community. To this end, we proposed [PEP 783](https://peps.python.org/pep-0783/), which standardizes a platform for running Python in the browser runtimes called PyEmscripten. After over a year of discussion and refinement, this proposal was accepted, enabling package maintainers to build and publish packages for the PyEmscripten platform and make them available across all environments that implement PyEmscripten. We also stabilized the existing Pyodide build toolchain and evolved it into a form that is accessible to all package maintainers, enabling developers to easily build packages for the PyEmscripten platform. Furthermore, we added PyEmscripten platform support to [`cibuildwheel`](https://cibuildwheel.pypa.io/en/stable/), to make it easier for others to adopt support for the PyEmscripten platform. While the ecosystem is still adopting this standard, we hope every Python package will have a wheel that works with WebAssembly in the future. We are also actively working with major package maintainers to add PyEmscripten builds. If you encounter a package that isn’t supported yet, let us know on Discord or GitHub, and our team will work to get it built. You can also check out our [EuroPython 2026 talk: “Python Everywhere: The State of Python on WebAssembly”](https://youtu.be/HklunTc9giA?si=wqeOjDl9qNe6qtB2) to see how we made this possible. The large ecosystem of data science and machine learning packages makes Python the natural choice for building intelligent agents and AI pipelines. But bringing these to Python Workers historically presented a challenge: libraries such as `openai` and `langchain` rely on HTTP clients like `requests` or `httpx` to communicate with external APIs. However, because of missing low-level socket operations support in Python Workers, these HTTP clients didn’t work properly. To solve this, we contributed upstream to ensure these HTTP clients can route requests directly through the JavaScript `fetch` API in WebAssembly environments. Combined with our new support for low-level socket operations as explained in [the previous section](https://blog.cloudflare.com#using-postgresql-and-mysql-with-hyperdrive), this makes the entire networking stack work seamlessly inside Python Workers. As a result, you can now run AI libraries like `openai`, `langchain`, and `mcp` natively in Python Workers. You can also combine them with Workers AI to run serverless inference on GPUs in Cloudflare’s network, or proxy requests through Cloudflare AI Gateway. The example below shows a way to run Worker AI models in langchain, using the [langchain-cloudflare](https://github.com/cloudflare/langchain-cloudflare) package: We have assembled a collection of production-ready patterns in our [python-workers-examples](https://github.com/cloudflare/python-workers-examples) repository. Here are some ways you can combine Python Workers with the Cloudflare ecosystem. Building a full-stack AI application often means connecting multiple services such as storage, queuing, and inference. [This example](https://github.com/cloudflare/python-workers-examples/tree/main/image-redraw) shows how to build an AI-driven image-to-image generator purely in Python Workers. It accepts user requests, drops them into a Cloudflare Queue, and uses Workflows to orchestrate the image generation step via Workers AI, and stores the image to an R2 bucket. Consuming a firehose of real-time events usually requires a dedicated server to maintain the connection. In this example, we use [a Python Worker to connect to the ATProto/Bluesky Jetstream WebSocket](https://github.com/cloudflare/python-workers-examples/tree/main/websocket-stream-consumer). By backing this connection with a Durable Object, the Python Worker can maintain long-lived state, ensuring that the WebSocket connection stays alive. [Build and deploy an MCP server](https://github.com/cloudflare/python-workers-examples/tree/main/mcp-server) using the official Python MCP package to give your AI assistants access to edge data. [Building a RAG system](https://github.com/cloudflare/python-workers-examples/tree/main/vectorize-rag) using Workers AI and Vectorize, Cloudflare’s vector database. We’ve updated our docs across Cloudflare products to include Python example code. Nearly everywhere where there is a code example showing how to do something in TypeScript, there’s also a code example in Python. We’re committed to continuing to include Python examples across all of our products. You can toggle code snippets between JavaScript, TypeScript, and Python throughout our developer documentation. Reaching GA is just the start. We have many plans to make Python Workers better, including making Python Workers more performant and memory efficient, as well as supporting more packages. Keep telling us what you want to build on Python Workers, and we’ll keep pushing the bounds of what is possible. Check out [Python Workers documentation](https://developers.cloudflare.com/workers/languages/python/) and start building your first Python Worker!