Deploying a Django App

Django's built-in runserver is explicitly documented as unsuitable for production — it's single-threaded, has no process management, and serves static files inefficiently. A production deployment instead runs your application through a WSGI server like Gunicorn (or an ASGI server like Uvicorn/Daphne if you use async views or Channels), which Gunicorn workers handle concurrently, fronted by a reverse proxy like nginx that terminates TLS, serves static/media files directly, and forwards dynamic requests to Gunicorn over a Unix socket or local port.

Gunicorn is invoked with something like gunicorn myproject.wsgi:application --workers 3 --bind 0.0.0.0:8000, and the worker count is typically set to roughly (2 x CPU cores) + 1. Django itself does not serve static files (CSS, JS, images) efficiently or at all with DEBUG=False, so production deployments run python manage.py collectstatic to gather every app's static assets into STATIC_ROOT, then either let nginx serve that directory directly or use WhiteNoise middleware to serve compressed, cache-busted static files straight from the Django process itself, which is simpler when you don't want to manage a separate nginx static-file config.

Production deployments almost always use a managed database service (Amazon RDS, DigitalOcean Managed Postgres, or a self-hosted Postgres container with backups) rather than SQLite, which is fine for development but doesn't handle concurrent writes well. During deployment, python manage.py migrate must run against the production database before the new application code starts serving traffic — most teams run this as an explicit release step (a Kubernetes init container, a pre-deploy hook, or a CI/CD pipeline stage) rather than automatically on every container boot, to avoid multiple app instances racing to apply the same migration simultaneously.

A typical production Docker setup uses a Dockerfile that installs dependencies, runs collectstatic, and starts Gunicorn as the container's entrypoint, orchestrated alongside a Postgres container and an nginx container via docker-compose.yml (or Kubernetes manifests for larger deployments). nginx is configured as a reverse proxy that terminates TLS certificates (often via Let's Encrypt/Certbot), serves the STATIC_ROOT volume directly for speed, and proxies everything else to the Gunicorn container's internal port, which keeps Django itself completely unreachable from the public internet.