Cloudflare Python Workers 정식 출시(GA)

We introduced Python Workers two years ago, providing a way to run Python applications 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 . 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 , it gave us the perfect environment to run a Wasm-compiled Python interpreter. By using Pyodide , 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: 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 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: 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. $ 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: 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. 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 or ASGI interface. You can find more information about using each web framework in the Python Workers documentation . 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 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 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" : "<example id: 57b7076f58be42419276f058a8968187>" , } ] Then, connect to Hyperdrive using the database drivers you are familiar with: import aiomysql from workers import WorkerEntrypoint class Default ( WorkerEntrypoint ): async def fetch (self, request): hd = self .env. HYPERDRIVE_MYSQL conn = await aiomysql.connect( host = hd.host, port = int (hd.port), user = hd.user, password = hd.password, db = hd.database, ssl = None , ) cur = await conn.cursor() await cur.execute( "SELECT username FROM user" ) r = await cur.fetchall() await cur.close() conn.close() You can refer to the Hyperdrive Python Workers documentation to find out how you can use Hyperdrive in Python Workers, and which packages are currently supported. Expanding the WebAssembly package ecosystem Because Python Workers run ins