Django vs FastAPI on Cloudflare Workers

Django vs FastAPI on Cloudflare Workers: Which One Should You Pick?

Choose Django when you already own a Django application or need a full product backend. Choose FastAPI when you are starting a typed API, webhook service, or I/O-heavy edge endpoint from scratch. Keep either app on its current origin if a required package, process model, or stateful workload does not fit the Workers runtime.

Cloudflare changed the premise on September 2, 2026. Python Workers can now host WSGI and ASGI applications directly through adapters in the workers module. WSGI is the traditional synchronous Python web contract. ASGI is its asynchronous successor, built for overlapping I/O, streaming, and long-lived connections. Cloudflare's release examples explicitly pair Django with WSGI and FastAPI with ASGI, although Django can use either protocol.

Django is the safer migration choice when its integrated product surface is already carrying business value. Cloudflare now documents both WSGI and ASGI entrypoints, plus a django-cf path for D1 and Durable Objects.

FastAPI is the cleaner greenfield choice when the deliverable is an API rather than an admin-backed web product. Cloudflare provides the ASGI server layer, so the Worker does not need to run Uvicorn or manage a socket.

Price Is a Tie Until CPU Time Diverges

There is no framework-price advantage. Pricing was verified on September 5, 2026 against live first-party pages: Django is free and open source under its BSD license, FastAPI uses the MIT license, and Workers Paid starts at $5 per account per month.

That $5 includes 10 million requests and 30 million CPU milliseconds per month. Additional requests cost $0.30 per million, and additional CPU costs $0.02 per million CPU milliseconds. Static Asset requests are free and unlimited. Workers Free includes 100,000 requests per day, but its 10 ms CPU allowance per invocation makes it a poor baseline for comparing nontrivial framework applications.

Normalize both frameworks onto the same workload and the result is deliberately boring. At 15 million dynamic requests per month and 7 ms average CPU per request, either framework costs $8 per month: $5 base, $1.50 in request overage, and $1.50 in CPU overage. At 100 million requests and the same 7 ms average, either costs $45.40 per month.

The sensitivity calculation is more useful than a made-up framework benchmark. Once both applications have exhausted the included CPU pool, every 1 ms of average CPU difference changes the bill by $0.30 at 15 million requests and $2 at 100 million requests. A measured 5 ms gap is therefore worth $1.50 or $10 per month at those traffic levels. That is far too small to justify a framework rewrite on compute price alone.

There is no vendor-price crossover point. One choice becomes cheaper only when its measured CPU time, supporting services, or maintenance burden differs. A fast framework wrapped around slow database calls will not rescue the architecture, and an integrated framework that removes weeks of replacement work can be the cheaper system even if a microbenchmark favors the other one.

Migration Path: Django Wins Existing Systems, FastAPI Wins New APIs

The adapter change is small; the application migration is not. Both frameworks need only a thin entrypoint, but everything behind that entrypoint still has to fit Cloudflare's package, storage, filesystem, and lifecycle model.

Django Cloudflare Workers Migration: The Adapter Is the Easy Part

Django can keep its standard WSGI application object and hand it to Cloudflare's adapter:

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

That is enough to bridge an incoming Workers request into Django's WSGI callable. It does not migrate the database, persistent files, scheduled jobs, session strategy, or every third-party Django package.

Cloudflare's new Django package guide gives the framework a genuinely native storage route. The django-cf package supplies SQLite-compatible backends for D1 and Durable Objects. Both drive Django's synchronous ORM, so Cloudflare instructs you to serve that configuration through WSGI. For a CRUD product that already depends on models, forms, auth, and admin, preserving those layers can save far more work than changing frameworks could save in runtime cost.

The wall appears when the existing system assumes a conventional server. A database driver may need a native wheel that Workers cannot load. User uploads cannot live on the isolate filesystem. A process-local scheduler or thread pool cannot be carried over. Django support means the request protocol works; it does not certify the whole installed application.

FastAPI Cloudflare Workers Migration: Best for a Narrow Service

FastAPI's direct adapter is smaller because the framework already speaks ASGI:

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

Cloudflare supplies the ASGI server role normally filled by Uvicorn. FastAPI keeps its route declarations, Pydantic validation, dependency injection, and generated OpenAPI documentation. A new webhook receiver, typed JSON API, or binding-backed service therefore starts with less application machinery than Django.

The trade is assembly work. FastAPI deliberately does not prescribe a database or data model. It also does not include Django's content admin. You choose those pieces, check each package against the Workers environment, and own the integration. That is an advantage for a focused service and a tax for a product whose operators need a back office on day one.

Migration winner: Django for an application that is already Django; FastAPI for a new API. Rewriting a working Django system into FastAPI merely because both now run at the edge is the wrong project.

WSGI vs ASGI Cloudflare: FastAPI Wins Concurrency, Django Keeps a Choice

ASGI is the stronger request model for a new I/O-heavy service, but WSGI is the documented path for Django's Cloudflare ORM integration. Protocol choice follows the workload, not a generic claim that async is always faster.

WSGI presents the application as a synchronous callable. Cloudflare's current WSGI adapter runs that callable inside the Worker's asynchronous fetch handler, bridges the request body from a JavaScript ReadableStream, and streams the application's response iterable back to the client. This is a compatibility path for mature synchronous applications, not a second web server running inside the isolate.

ASGI lets the application await network and storage operations without holding the request path in a synchronous call. Cloudflare's adapter also maps ASGI WebSocket events onto Workers WebSockets. FastAPI is built on that model. Django can use it too, so "Django" and "WSGI" are not synonyms.

The storage choice can reverse the protocol decision. Cloudflare says its D1 and Durable Objects backends for Django both drive the synchronous ORM and should be served through WSGI. If the reason for choosing Django is its ORM, following that documented WSGI path is more coherent than forcing an ASGI label onto a synchronous data layer.

For FastAPI, async only helps when the work can overlap. An endpoint that spends most of its time on serial validation or CPU-heavy Python still consumes CPU. An endpoint waiting on several independent HTTP or Cloudflare binding operations has a clearer reason to use ASGI.

Startup Behavior: The FastAPI Lifespan Surprise

Django over WSGI currently has the more predictable startup model on Workers. FastAPI still works, but its lifespan hooks do not behave like a long-running Uvicorn process.

Cloudflare reduces Python cold-start work through deployment snapshots. During deployment, the platform creates a V8 isolate, injects Pyodide, executes the Worker entry module and its top-level imports, then snapshots WebAssembly memory. A request can load that snapshot instead of rebuilding the Python environment from zero. Global-scope code must still parse and execute within the platform's 1-second startup limit. Cloudflare documents that lifecycle directly.

FastAPI's normal lifespan contract is process-shaped: startup code runs once before the application accepts requests, and shutdown code runs once after it finishes. The current Cloudflare ASGI adapter source does something materially different. Its fetch function starts the ASGI application, sends a lifespan startup event, handles one request, and then sends shutdown. The source comment describes one startup and shutdown cycle before and after the request.

That makes lifespan code request-scoped on the current adapter. A model load, connection-pool build, schema warmup, or remote configuration fetch placed there can repeat rather than amortize across an isolate. This is not a reason to reject FastAPI. It is a reason to make lifespan work cheap and idempotent, and to move safe deterministic initialization into code that can benefit from Cloudflare's deployment snapshot.

Django's WSGI application is created at module scope in Cloudflare's example and has no ASGI lifespan cycle. Its initialization is therefore part of the global startup path, which makes the 1-second ceiling the constraint. If you choose Django's ASGI entrypoint and use lifespan-aware components, audit them under the same adapter behavior.

Python Workers Frameworks Share the Same Package Wall

This category is a tie, and it can disqualify both frameworks. Django and FastAPI run through the same Pyodide environment inside V8, so neither escapes the package, memory, filesystem, or startup boundaries.

Cloudflare's package documentation says pywrangler bundles dependencies declared in pyproject.toml. Supported sources include pure Python and PyEmscripten packages from PyPI, plus packages shipped with Pyodide. PyEmscripten is the WebAssembly-targeted wheel format. Cloudflare still describes that ecosystem as early, and some packages have no compatible wheel.

The hard platform checks are straightforward:

• The uncompressed Worker bundle cannot exceed 64 MiB on Free or Paid.
• Each isolate has 128 MB of memory.
• Global-scope startup must complete within 1 second.
• The Python filesystem is ephemeral and private to an isolate.
• threading and multiprocessing can be imported but do not function in the WebAssembly VM.

The filesystem point breaks more migrations than the adapter signature suggests. Temporary files are fine. Persistent uploads, generated reports, SQLite files used as durable state, and shared on-disk caches are not. Put durable objects in D1, Durable Objects, KV, or R2 according to the access pattern, not in a directory that disappears with the isolate. The exact boundaries are documented in Cloudflare's Python standard-library guide.

Package compatibility is binary before performance is interesting. Build the real dependency graph, not a hello-world subset. A successful import in desktop CPython proves nothing about the availability of its native extensions in Pyodide.

Operating Fit: Django Wins Products, FastAPI Wins Services

Django wins when the unit of work is a product; FastAPI wins when it is a service. The distinction is more durable than framework throughput on a synthetic route.

Winner for an Admin-Backed Product: Django

Django bundles user authentication, content administration, an ORM, templates, middleware, and other common web-product facilities. Its official overview calls out authentication and content administration explicitly. If a small operations team needs to manage customers, orders, permissions, and editorial records, the built-in admin can be more valuable than shaving a few milliseconds from framework overhead.

On Workers, django-cf gives that integrated model a D1 or Durable Objects path. The cost is tighter coupling to a synchronous ORM and a larger framework surface to fit inside the runtime limits.

Winner for a Typed API Service: FastAPI

FastAPI builds around OpenAPI, JSON Schema, Pydantic validation, and dependency injection. Its feature documentation also makes the trade explicit: database and data-model choices remain open. That is the right shape for an API gateway, webhook receiver, model endpoint, or small service that talks to bindings and remote APIs.

The missing integrated admin and ORM are not flaws when the service does not need them. They become a delivery cost the moment a nontechnical operator needs a back office.

Winner for Raw Speed: Not Proven on Workers

TechEmpower's independent suite historically placed FastAPI under Uvicorn among the fastest Python frameworks, according to FastAPI's benchmark page. TechEmpower measured standardized JSON, database, ORM, template, and related workloads. It did not measure Cloudflare's Pyodide adapters, and the project was sunset on March 24, 2026. Those results are an attributed historical signal, not a Workers deployment forecast.

Cloudflare has not published a Django-versus-FastAPI benchmark through these adapters. Raw speed on Workers therefore remains unproven until a representative route includes its validation, bindings, database calls, response shape, startup behavior, and Workers CPU metrics.

What Switching Actually Costs, and Who Should Not Switch

Do not switch frameworks just to gain Cloudflare support. Both now have it. Switch only when the target framework removes more application work than the migration creates.

A Django-to-FastAPI rewrite means replacing or separating models, migrations, admin screens, authentication flows, middleware, templates, and any package that expects Django's request lifecycle. The result can be excellent for a narrow API, but it is not a deployment setting. If the admin and ORM are heavily used, the switch destroys leverage before it creates any.

A FastAPI-to-Django move makes sense only when the product has outgrown a service-shaped architecture and needs Django's integrated operational surface. Otherwise it adds conventions and components that a small API does not need.

FastAPI can mount a Django WSGI application under a path through a2wsgi.WSGIMiddleware. That can support a staged decomposition on conventional servers. On Workers it adds another package and another protocol boundary, while Cloudflare's starter paths document each framework separately. Treat a combined Worker as a custom integration to prove, not the default shortcut.

Whichever direction you consider, price these migration surfaces:

• Data: schema compatibility, migrations, transaction behavior, and the move to D1, Durable Objects, or another reachable store.
• Files: static assets can use Workers Static Assets, while persistent user media needs durable object storage such as R2.
• Background work: replace process-local schedulers, thread pools, and child processes with platform-native asynchronous work.
• Dependencies: resolve the complete lockfile against Python Workers, then inspect the 64 MiB bundle and 1-second startup result.
• Operations: rebuild logs, error alerts, deployment rollback, secrets, and a route-level performance baseline.

Who should not switch? A stable Django monolith with a working database and substantial admin workflow should not become FastAPI for fashion. A FastAPI service that depends on unavailable native wheels should not move to Workers simply because the framework now has a docs page. A team whose latency is dominated by a distant database should fix data placement before changing the request framework.

The Monday Move

Prove one representative route next week, not the whole application. Choose the route that carries the package, state, and latency characteristics of the production system, then use it to eliminate the wrong options quickly.

Django and FastAPI on Cloudflare Workers FAQ