Cloudflare Python Workers now accept applications that follow the WSGI or ASGI specifications, meaning you can bring existing Django, Flask, FastAPI, or Starlette code to the edge without rewriting the framework layer. This expands the edge runtime to cover the majority of Python web stacks, which directly impacts deployment footprints, latency expectations, and the security perimeter for services that were previously hosted on traditional VMs or containers.
Supported frameworks and entry points
The runtime distinguishes two entry modules:
workers.wsgifor WSGI‑compliant frameworks such as Django and Flask.workers.asgifor ASGI‑compliant frameworks such as FastAPI and Starlette.
Both modules expose a convenience function that creates the required WorkerEntrypoint class behind the scenes. For example, a minimal Flask deployment can be expressed as:
from workers import wsgi
from flask import Flask
app = Flask(__name__)
Default = wsgi.entrypoint(app)When more control over the request lifecycle is needed, the same effect can be achieved by subclassing WorkerEntrypoint and invoking wsgi.fetch (or asgi.fetch) directly:
from workers import wsgi, WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
return await wsgi.fetch(app, request, self.env)Implementation pattern
Practically, the change means you import the appropriate module, obtain the framework’s application object (e.g., get_wsgi_application() for Django), and hand it to the Workers entry point. No additional build steps or container images are required; the Workers platform bundles the Python runtime and the framework code together at deployment time.
Because the entry point is a regular WorkerEntrypoint, existing lifecycle hooks—such as fetch for request handling and env for environment variables—remain available. This continuity lets you retain familiar patterns for configuration, secret injection, and request inspection.
Operational considerations
Deploying a WSGI/ASGI app to Workers shifts the execution environment from a data‑center VM to a distributed edge node. Practitioners should evaluate:
- Cold‑start latency and warm‑instance behavior, which now include framework initialization.
- Resource caps inherent to Workers (CPU time, memory) that may affect heavy‑weight frameworks or large model inference workloads.
- Observability pipelines—logs and metrics must be collected from the Workers platform rather than from a traditional host.
- Version compatibility: the framework must be compatible with the Python version provided by the Workers runtime.
Security‑focused teams should note that request handling now occurs at the edge, expanding the attack surface to every point of presence. The same request object is passed to the framework, so any input validation or sanitization logic remains critical. Environment variables are still supplied via self.env, so secret management practices should continue unchanged, but the storage location moves to the edge platform.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
AI engineers can expose model inference APIs built with FastAPI directly from the edge, reducing round‑trip time for end users. Cloud and platform engineers gain a unified deployment model for both static assets and dynamic Python services, simplifying CI/CD pipelines. DevOps and SRE staff should update their deployment scripts to include the appropriate workers.wsgi or workers.asgi import and verify that framework initialization fits within Workers’ execution limits. Security engineers must extend threat modeling to include edge execution and ensure that existing validation, rate‑limiting, and secret‑handling controls are still enforced in the new context.
Going forward, monitor the Workers release notes for any adjustments to supported Python versions, framework compatibility matrices, or changes to resource quotas. Testing framework behavior under edge load patterns will be essential before moving production traffic.
