Python becomes a supported Workers language
Cloudflare made Python Workers generally available on 21 September after roughly two years in preview. Python is now a first-class supported language on the Workers platform, with direct access to Cloudflare bindings rather than a JavaScript wrapper layer. Cloudflare says the production release is built around the same Pyodide-in-WebAssembly execution model used during preview, but with the runtime, deployment path and platform integration promoted to general availability.
The release gives Python applications access to Workers services such as storage and AI bindings through native Python APIs. It also puts common web frameworks on a documented path at the edge: Cloudflare provides connectors for WSGI and ASGI applications, including Django, Flask and FastAPI, so existing application structures can be adapted without rewriting the request layer in JavaScript.
Database drivers now have a direct networking path
Cloudflare has also filled one of the preview’s larger compatibility gaps by adding socket support. Python Workers can use a Workers-backed socket implementation for outbound TCP connections, which lets compatible database drivers connect through Hyperdrive rather than depending on browser-style networking alone.
That matters for ordinary server applications because database access is often the point where a Python framework stops looking portable across runtimes. Cloudflare documents Python examples for PostgreSQL and MySQL through Hyperdrive, but application behaviour still depends on the driver, compatibility date, database configuration and the limits of the Workers environment.
WebAssembly remains the package boundary
General availability does not turn Workers into ordinary native CPython. The runtime still uses Pyodide inside WebAssembly. Pure-Python packages are the easiest fit, while packages containing native C, C++ or Rust extensions need WebAssembly-compatible builds. Cloudflare points to the emerging PyEmscripten packaging work around PEP 783 as the route for expanding that ecosystem, and says adoption is still in progress.
Networking libraries also need runtime-specific testing. urllib3’s current security policy explicitly classifies its Emscripten module as experimental, which is a useful compatibility warning. A 2025 redirect advisory involving browser and Node.js runtimes was fixed in urllib3 2.5.0; it is historical context and does not establish a current Python Workers vulnerability.
What the release establishes and what still needs testing
The confirmed change is the supported production path: Python Workers are generally available, common framework adapters are documented, and database connectivity through the Workers socket layer and Hyperdrive is part of the platform. Hacker News supplied the discovery lead for this story but is not evidence for the product claims.
The practical limits remain workload-specific. Cold starts, memory use, package availability, native-extension compatibility and HTTP or TLS semantics can differ from a conventional CPython server. Representative production tests with pinned package versions are still needed before assuming that an existing application will behave identically after moving to the Workers runtime.