{"slug": "python-workers-are-now-generally-available", "title": "Python Workers are now generally available", "summary": "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.", "body_md": "# Python Workers are now generally available\n\nWe 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”.\n\nToday, Python Workers are now generally available (GA).\n\nWhat 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/).\n\n``` python\nfrom fastapi import FastAPI, Request\nfrom workers import asgi, WorkerEntrypoint\n\napp = FastAPI()\n\n@app.get(\"/\")\nasync def root(request: Request):\n    env = request.scope[\"env\"]\n    return await env.AI.run(\n        \"@cf/openai/gpt-oss-120b\",\n        {\n            \"instructions\": \"You are a friendly assistant.\",\n            \"input\": \"What is the origin of the phrase Hello, World?\",\n        },\n    )\n\nDefault = asgi.entrypoint(app)\n```\n\n## The journey behind Python Workers\n\nBringing 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.\n\nOur 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.\n\nThe 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.\n\n## Python is now a first-class language in the Cloudflare Workers runtime\n\nPython 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:\n\n``` python\nfrom pyodide.ffi import to_js\nimport js\n\nself.env.QUEUE.send(to_js({\"key\": \"value\"}, dict_converter=js.Object.fromEntries))\n```\n\nThis 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:\n\n```\nself.env.QUEUE.send({\"key\": \"value\"})\n```\n\n## Web frameworks: FastAPI, Django, and Flask\n\nYou 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.\n\nLet’s say you have a simple FastAPI web application:\n\n``` python\nfrom fastapi import FastAPI\n\napp = FastAPI()\n\n@app.get(\"/\")\nasync def root():\n    message = \"Hello, world!\"\n    return {\"message\": message}\n```\n\nIn native environments, you would use a web server such as `uvicorn` to run this application.\n\n``` bash\n$ uvicorn main:app\n```\n\nIn Python Workers, you can run the same application using the workers.asgi package we provide, just by adding this snippet to your code:\n\n``` python\nfrom workers import asgi\n\nclass Default(WorkerEntrypoint):\n    async def fetch(self, request):\n        return await asgi.fetch(app, request, self.env)\n\n# or equivalently\nDefault = asgi.entrypoint(app)\n```\n\nSimilarly, you can use `workers.wsgi` package to run synchronous web applications such as Django.\n\n``` python\nfrom workers import WorkerEntrypoint, wsgi\nfrom your_django_app.wsgi import app\n\nDefault = wsgi.entrypoint(app)\n```\n\n### So, what happens under the hood?\n\nPython 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.\n\nIn 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.\n\nInstead, 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.\n\nThese 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.\n\nYou can find more information about using each web framework in the [__Python Workers documentation__](https://developers.cloudflare.com/workers/languages/python/packages/).\n\n## Using PostgreSQL and MySQL with Hyperdrive\n\nIf 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.\n\nPreviously, 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.\n\nWhen 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.\n\nThis 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:\n\n```\n\"hyperdrive\": [\n    {\n        \"binding\": \"HYPERDRIVE_MYSQL\",\n        \"id\": \"<example id: 57b7076f58be42419276f058a8968187>\",\n    }\n]\n```\n\nThen, connect to Hyperdrive using the database drivers you are familiar with:\n\n``` python\nimport aiomysql\n\nfrom workers import WorkerEntrypoint\n\nclass Default(WorkerEntrypoint):\n    async def fetch(self, request):\n        hd = self.env.HYPERDRIVE_MYSQL\n        conn = await aiomysql.connect(\n            host=hd.host,\n            port=int(hd.port),\n            user=hd.user,\n            password=hd.password,\n            db=hd.database,\n            ssl=None,\n        )\n\n        cur = await conn.cursor()\n        await cur.execute(\"SELECT username FROM user\")\n        r = await cur.fetchall()\n        await cur.close()\n        conn.close()\n```\n\nYou 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.\n\n## Expanding the WebAssembly package ecosystem\n\nBecause 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.\n\nWe 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.\n\nTo 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.\n\nWe 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 , to make it easier for others to adopt support for the PyEmscripten platform.\n\nWhile 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.\n\nYou 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.\n\n## Building AI agents and pipelines in Python\n\nThe 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.\n\nTo 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://docs.google.com/document/d/1o02vM_SxUxyJlBXICFff33QEuHrjJ3y5t-eAMsX1v2w/edit?tab=t.0#bookmark=id.v8myp1sqlebv), this makes the entire networking stack work seamlessly inside Python Workers.\n\nAs 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.\n\nThe example below shows a way to run Worker AI models in langchain, using the [__langchain-cloudflare__](https://github.com/cloudflare/langchain-cloudflare) package:\n\n``` python\nfrom langchain_cloudflare import ChatCloudflareWorkersAI\nfrom langchain_core.output_parsers import StrOutputParser\nfrom langchain_core.prompts import PromptTemplate\nfrom workers import Response, WorkerEntrypoint\n\nclass Default(WorkerEntrypoint):\n    async def fetch(self, request):\n        prompt = PromptTemplate.from_template(\n            \"In one sentence, describe a great day in the life of an {profession}.\"\n        )\n        llm = ChatCloudflareWorkersAI(\n            model_name=\"@cf/meta/llama-3.3-70b-instruct-fp8-fast\",\n            binding=self.env.AI,\n            max_tokens=64,\n        )\n        chain = prompt | llm | StrOutputParser()\n\n        result = await chain.ainvoke({\"profession\": \"electrician\"})\n        return Response.json({\"result\": result})\n```\n\n## What you can build today\n\nWe 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.\n\n### Asynchronous AI orchestration\n\nBuilding 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.\n\n### Real-time stream processing with Bluesky Jetstream\n\nConsuming 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.\n\n### More examples to explore\n\n#### Model Context Protocol (MCP) Server\n\n[__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.\n\n#### Retrieval-Augmented Generation (RAG) system with Vectorize\n\n[__Building a RAG system__](https://github.com/cloudflare/python-workers-examples/tree/main/vectorize-rag) using Workers AI and Vectorize, Cloudflare’s vector database.\n\n## Python code examples across the Cloudflare developer docs\n\nWe’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.\n\n## What’s next?\n\nReaching 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.\n\nKeep 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!", "url": "https://wpnews.pro/news/python-workers-are-now-generally-available", "canonical_source": "https://blog.cloudflare.com/python-workers-ga/", "published_at": "2026-09-21 13:00:00+00:00", "updated_at": "2026-09-21 13:23:54.766789+00:00", "lang": "en", "topics": ["ai-infrastructure", "developer-tools", "ai-tools"], "entities": ["Cloudflare", "Python Workers", "FastAPI", "Django", "Flask", "Pyodide", "Workers AI", "Cloudflare Developer Platform"], "alternates": {"html": "https://wpnews.pro/news/python-workers-are-now-generally-available", "markdown": "https://wpnews.pro/news/python-workers-are-now-generally-available.md", "text": "https://wpnews.pro/news/python-workers-are-now-generally-available.txt", "jsonld": "https://wpnews.pro/news/python-workers-are-now-generally-available.jsonld"}}