Python Workers are now generally available Cloudflare announced that Python Workers are now generally available, making Python a first-class, fully supported language on the Cloudflare Developer Platform two years after the feature was first introduced. The GA release lets developers run Python frameworks including FastAPI, Django, and Flask inside Python Workers and connect natively to Cloudflare bindings such as Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, and Workflows without writing JavaScript glue code. Cloudflare built the runtime on WebAssembly, which it has supported since 2018, using the Pyodide Python interpreter. Python Workers are now generally available 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/ . python from fastapi import FastAPI, Request from workers import asgi, WorkerEntrypoint app = FastAPI @app.get "/" async def root request: Request : env = request.scope "env" return await env.AI.run "@cf/openai/gpt-oss-120b", { "instructions": "You are a friendly assistant.", "input": "What is the origin of the phrase Hello, World?", }, Default = asgi.entrypoint app The journey behind Python 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 is now a first-class language in the Cloudflare Workers runtime 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: python from pyodide.ffi import to js import js self.env.QUEUE.send to js {"key": "value"}, dict converter=js.Object.fromEntries 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: self.env.QUEUE.send {"key": "value"} Web frameworks: FastAPI, Django, and Flask 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: python from fastapi import FastAPI app = FastAPI @app.get "/" async def root : message = "Hello, world " return {"message": message} In native environments, you would use a web server such as uvicorn to run this application. bash $ uvicorn main:app In Python Workers, you can run the same application using the workers.asgi package we provide, just by adding this snippet to your code: python from workers import asgi class Default WorkerEntrypoint : async def fetch self, request : return await asgi.fetch app, request, self.env or equivalently Default = asgi.entrypoint app Similarly, you can use workers.wsgi package to run synchronous web applications such as Django. python from workers import WorkerEntrypoint, wsgi from your django app.wsgi import app Default = wsgi.entrypoint app So, what happens under the hood? 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/ . Using PostgreSQL and MySQL with Hyperdrive 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: "hyperdrive": { "binding": "HYPERDRIVE MYSQL", "id": "