Cloudflare Python Workers Reach GA: FastAPI, Django, and Postgres at the Edge

Cloudflare's Python Workers moved out of beta this week, and the changelog is the kind that actually changes what you'd reach for at the edge: native bindings with no JavaScript glue code, real FastAPI, Django, and Flask support, Postgres and MySQL connections through Hyperdrive, and a brand-new Python packaging standard the team spent over a year getting accepted. A second story rode along in the same wave of social posts — Quick Tunnels, pitched by one widely-shared post as a fresh ngrok killer — except it isn't new. Here's what actually shipped, what it replaces, and where the two stories diverge.

TL;DR

What "GA" actually removes: the JavaScript glue code

The most concrete change in this release is boring in the best way — it deletes code you used to have to write. Before GA, passing a Python dict into a Cloudflare Queue meant writing explicit conversion glue:

from pyodide.ffi import to_js
import js

self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))

Cloudflare says that conversion now happens automatically inside the Workers runtime and the Python SDK, so the same call becomes:

self.env.QUEUE.send({"key": "value"})

That's a small snippet, but it was a real source of friction — Cloudflare's own post calls it "a common source of error for both humans and AI agents," which is a notable detail on its own: agentic coding tools writing Python Workers code were reportedly tripping on the JS/Python boundary often enough that Cloudflare called it out by name in a GA announcement.

FastAPI, Django, and Flask now "just work"

Python Workers ship built-in connectors for the two standard interfaces the Python web ecosystem already runs on: ASGI (async, used by FastAPI and Starlette) and WSGI (sync, used by Django and Flask). A FastAPI app now deploys with one extra line:

from workers import asgi
from your_app import app

Default = asgi.entrypoint(app)

Cloudflare's technical explanation for why this works is worth understanding rather than treating as magic: in a normal deployment, a server like Uvicorn or Gunicorn handles concurrent connections and threading, while FastAPI only handles application logic. On Cloudflare, the Workers platform itself is already the server — it already load-balances and scales globally — so the workers.asgi/workers.wsgi connectors don't run a server inside the Worker at all. They're a thin translation layer that converts an incoming native JavaScript request into the WSGI/ASGI structures Python frameworks expect, then pipes the response back out. Any framework built on either standard interface, not just the three named, gets this for free.

Real database connections: the socket problem Cloudflare had to solve

This is the part of the release with the most engineering depth behind it. Python database drivers like asyncpg and aiomysql are built on the standard library's socket module, which normally makes POSIX system calls to the OS to open a TCP connection. Inside a WebAssembly sandbox, those POSIX networking syscalls are stubbed out and always fail — which meant, until now, Python Workers simply couldn't talk to a relational database at all.

Cloudflare's fix was to implement the socket syscalls themselves, translating standard Python socket operations into calls against the Workers connect API. Because the translation happens at the syscall level, existing database drivers don't need to know anything changed — they just work:

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,
        )
        cur = await conn.cursor()
        await cur.execute("SELECT username FROM user")
        rows = await cur.fetchall()

That same socket bridge is also what unlocked HTTP clients like requests and httpx for AI libraries — more on that below.

PEP 783: a bigger deal than it sounds

The least flashy-sounding item in the release notes might be the one with the widest blast radius outside Cloudflare entirely. Any Python package with native C, C++, or Rust extensions has to be cross-compiled to WebAssembly to run inside a Python Worker's Pyodide-based sandbox — and until now there was no standard way to do that, so Cloudflare's own team had to manually compile and host custom WebAssembly builds for every package it wanted to support. That's a maintenance burden that doesn't scale, and it locked Python Workers' package support behind whatever Cloudflare had personally gotten around to compiling.

Cloudflare's response was to propose PEP 783, a Python Enhancement Proposal standardizing "PyEmscripten" as a platform target for running Python in browser-style WebAssembly runtimes — accepted after more than a year of community discussion. Cloudflare also says it stabilized the existing Pyodide build toolchain into something any package maintainer can use, and added PyEmscripten support to cibuildwheel, the tool much of the Python packaging ecosystem already relies on to build wheels for multiple platforms. The practical upshot: once package maintainers adopt this, a Python package with native extensions can ship a WebAssembly-compatible wheel usable by any environment that implements PyEmscripten — not a Cloudflare-specific artifact, a general one. That's the kind of standards work that quietly outlives the announcement it shipped alongside.

AI agents in Python Workers: openai, langchain, and mcp

For a platform explainx.ai already tracks closely for MCP tooling and edge AI infrastructure, this is the section worth reading twice. Libraries like openai and langchain depend on HTTP clients (requests, httpx) that need real socket-level networking to reach external APIs — exactly what was missing before this release. Cloudflare says it contributed upstream fixes so these clients route requests through the JavaScript fetch API when running inside a WebAssembly environment, and combined with the new socket support, the result is that openai, langchain, and the mcp package now run natively inside a Python Worker:

from langchain_cloudflare import ChatCloudflareWorkersAI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import PromptTemplate
from workers import WorkerEntrypoint, Response

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        prompt = PromptTemplate.from_template(
            "In one sentence, describe a great day in the life of an {profession}."
        )
        llm = ChatCloudflareWorkersAI(
            model_name="@cf/meta/llama-3.3-70b-instruct-fp8-fast",
            binding=self.env.AI, max_tokens=64,
        )
        chain = prompt | llm | StrOutputParser()
        result = await chain.ainvoke({"profession": "electrician"})
        return Response.json({"result": result})

That means a Python-native MCP server, a RAG pipeline against Vectorize, or a LangChain agent chain can now run entirely at the edge — globally distributed, with Workers AI available for GPU inference in-network or proxied through Cloudflare AI Gateway — without standing up a separate Python backend at all. Cloudflare published a python-workers-examples repository with working patterns for exactly this, including an async image-generation pipeline (queue → Workflows → Workers AI → R2) and a real-time Bluesky Jetstream WebSocket consumer backed by a Durable Object for persistent state.

The other story: Quick Tunnels isn't actually new

A separate post from developer @byteHumi went semi-viral this week calling Quick Tunnels "incredibly useful" and telling people they "don't need to use that shitty ngrok now" — framing it as something that just shipped alongside Python Workers GA. Worth being precise here: it didn't. Quick Tunnels, invoked with cloudflared tunnel --url localhost:8080, has been a free part of Cloudflare Tunnel since at least 2021, generating a random trycloudflare.com subdomain that proxies to your local server with no account or domain setup required. It's capped at 200 concurrent requests and explicitly meant for testing and demos, not production traffic — named Cloudflare Tunnels remove that cap and add custom domains, Zero Trust policies, and an uptime SLA on eligible plans.

None of that makes Quick Tunnels less genuinely useful as an ngrok alternative for local webhook testing and quick demos — it's a real, free, one-command tool that solves a problem developers hit constantly. It's just not this week's news; it appears to have gotten swept into the same wave of Cloudflare-related posts because it was mentioned in adjacent social threads, not because Cloudflare announced or relaunched it alongside Python Workers GA.

How this fits Cloudflare's broader developer-platform push

This GA lands in the same run of Cloudflare developer-platform moves explainx.ai has tracked this year: Cloudflare Drop let anyone deploy a static folder to the edge with no account back in July, and the Monetization Gateway opened up per-request stablecoin payments for APIs and MCP tools that same month. Python Workers GA is a heavier, more structural piece of that same strategy — removing an entire language's worth of friction from Cloudflare's edge platform, rather than adding a new surface feature. Compared to how Vercel and Railway have generally leaned on their own managed runtimes, Cloudflare's bet here is standards-first: PEP 783 is explicitly designed to benefit the wider Pyodide and Python-on-WebAssembly community, not just Cloudflare's own platform.

Honest limitations

• This post is sourced to Cloudflare's own official blog post and X announcements — independent third-party benchmarks of Python Worker cold-start times, memory ceilings, or Hyperdrive connection-pool behavior at scale weren't available as of publication.
• PyEmscripten/PEP 783 adoption is early. Cloudflare's own post says "the ecosystem is still adopting this standard" and that most packages don't yet ship PyEmscripten wheels — the standard existing doesn't mean your specific dependency already has a compatible build.
• Quick Tunnels' 200-concurrent-request cap and lack of a persistence guarantee make it unsuitable for anything beyond testing, regardless of how it's being framed in social posts this week.
• "Untrusted code" support (Dynamic Python Workers) is mentioned in the announcement but not detailed with specific isolation guarantees in the material reviewed for this post — treat it as a capability to verify directly in Cloudflare's docs before relying on it for a security-sensitive use case.

What this means for builders

If you've been avoiding Cloudflare Workers for a Python-heavy stack — a FastAPI backend, a LangChain agent, anything touching Postgres — that's no longer a real blocker. The GA release specifically targets the friction that made Python Workers feel like a second-class citizen next to TypeScript: manual type conversion, no database sockets, and a locked-down package ecosystem are all addressed directly in this release. For local development and webhook testing, Quick Tunnels remains a genuinely good, free ngrok alternative — just don't mistake this week's renewed attention for a new feature, and don't reach for it past a demo or a test.

Related on explainx.ai

• Cloudflare Drop: Deploy a Folder to the Edge in Seconds — Cloudflare's earlier no-account instant-deploy tool
• Cloudflare Monetization Gateway: x402 Micropayments for APIs and MCP Tools — the same platform's per-request payment infrastructure
• What Is MCP (Model Context Protocol)? A Complete Guide — the protocol now natively runnable inside a Python Worker
• What Is a Webhook? How It Works — the exact local-testing problem Quick Tunnels and ngrok both solve
• What Is Vercel? How to Deploy Your App — a comparison point for a different deploy-platform philosophy
• What Is Railway? How to Deploy Beginners Guide — another managed-runtime alternative to Cloudflare's standards-first approach

Primary sources: Cloudflare — Python Workers are now generally available, September 21, 2026; @Cloudflare, @irvinebroque, and @ritakozlov on X; @byteHumi on X for the Quick Tunnels reaction.

This post reflects Cloudflare's official GA announcement and public developer reaction as of September 21, 2026. Feature availability, pricing, and package compatibility should be verified against Cloudflare's current documentation before production use.