Does Django Work With Cloudflare Pages?

Partially CompatibleLast verified: 2026-02-20

Django can work with Cloudflare Pages, but Pages is optimized for static sites and serverless functions, requiring you to either deploy Django elsewhere or use Pages Functions as an adapter.

Quick Facts

Compatibility
partial
Setup Difficulty
Moderate
Official Integration
No — community maintained
Confidence
high
Minimum Versions
Django: 3.2

How Django Works With Cloudflare Pages

Cloudflare Pages is fundamentally a static site hosting platform with optional serverless compute via Pages Functions. Django is a full server-side framework that needs a persistent runtime environment. Direct deployment isn't possible, but you have two paths: First, you can deploy your Django backend elsewhere (Railway, Heroku, a VPS) and use Cloudflare Pages exclusively for static frontend assets with Pages Functions to proxy API calls to your Django backend. Second, you can use Cloudflare Workers (not Pages) with a WSGI adapter to run Django, though this requires significant refactoring. Most developers choose the first approach—using Pages for the frontend (built assets) and keeping Django on a traditional server. Pages Functions can handle request routing, caching, and redirecting API calls to your backend. This architecture actually scales well since Pages' CDN caches your static assets globally while your Django instance handles dynamic logic. The developer experience is clean: build your Django API normally, deploy it anywhere, then configure your Pages project to serve built frontend files and route `/api/*` requests to your Django backend.

Best Use Cases

Decoupled architecture: Static frontend assets served globally via Pages CDN, with Django API backend handling business logic
JAMstack sites with Python backends: Blogs or content sites built with static site generators, using Django for admin interfaces and API endpoints
Multi-region API gateway: Using Pages Functions to proxy, cache, and rate-limit requests to a Django API deployed elsewhere
Hybrid apps: Next.js/SvelteKit frontends deployed on Pages with Django APIs for authentication, database operations, and server-side processing

Django + Pages: Proxy API via Pages Functions

bash
pip install django && npm install wrangler
javascript
// functions/api/[[route]].js - Pages Function proxying to Django
export async function onRequest(context) {
  const { request } = context;
  const url = new URL(request.url);
  const pathSegments = url.pathname.split('/').slice(2);
  const apiPath = pathSegments.join('/');
  
  const djangoBackend = 'https://your-django-api.com';
  const apiUrl = new URL(`${djangoBackend}/${apiPath}${url.search}`);
  
  const response = await fetch(apiUrl, {
    method: request.method,
    headers: request.headers,
    body: request.method !== 'GET' ? request.body : undefined,
  });
  
  const newResponse = new Response(response.body, response);
  newResponse.headers.set('Cache-Control', 'public, max-age=3600');
  return newResponse;
}

# Django settings.py
CORS_ALLOWED_ORIGINS = [
    'https://your-site.pages.dev',
]
CSRF_TRUSTED_ORIGINS = [
    'https://your-site.pages.dev',
]

Known Issues & Gotchas

critical

Cloudflare Pages doesn't support long-running server processes—Django needs a traditional server

Fix: Deploy Django to Railway, Render, or another platform designed for persistent backends. Use Pages Functions only for lightweight routing/caching logic.

critical

Cold starts and timeout limits with Pages Functions (10 second limit) make full Django deployment impractical

Fix: Keep Django completely separate from Cloudflare. Use Pages Functions only as a thin proxy layer if needed.

warning

CORS issues when frontend on Pages calls Django API on different domain

Fix: Configure Django's CORS_ALLOWED_ORIGINS to include your Pages domain, or use Pages Functions as a proxy to avoid cross-origin requests.

warning

Environment variables and secrets management across two deployments adds operational complexity

Fix: Use Cloudflare's environment variable system for Pages and separate secrets management for your Django host.

Alternatives

  • Next.js with Vercel—native full-stack support with serverless functions replacing Django's server role
  • FastAPI with Railway—lightweight Python async framework designed for cloud-native deployment alongside static frontend hosting
  • Express.js with Netlify—serverless backend alternative, lighter weight than Django for JAMstack architectures

Resources

Related Compatibility Guides

Explore more compatibility guides