Moving Django from runserver to production requires settings hardening, a WSGI/ASGI server, static/media strategy, and database backups.
Pre-deploy checklist
DEBUG = False- Set
ALLOWED_HOSTSand secureSECRET_KEYfrom env - Configure PostgreSQL (or managed DB) with connection pooling
- Run
migrateandcollectstatic - Use gunicorn/uvicorn behind nginx or a load balancer
- HTTPS, HSTS, secure cookies (
SESSION_COOKIE_SECURE) - Logging, monitoring (Sentry), and automated backups
Never in production
runserver, committed secrets, open ALLOWED_HOSTS = ['*'] without understanding, or serving user uploads without validation.
Important interview questions and answers
- Q: WSGI vs ASGI?
A: WSGI for traditional sync Django; ASGI (Daphne/Uvicorn) for async views and WebSockets. - Q: Where static files served?
A: nginx, S3+CDN, or WhiteNoise—not Django runserver. - Q: Zero-downtime migrations?
A: Backward-compatible schema changes, deploy code that works with old and new schema, then finalize.
Self-check
- Name three settings that must change for production.
- Why not use runserver in production?
Challenge
Local Django check
- Create a venv and
pip install django. - Run
django-admin startproject demo. - Run
python manage.py runserverand open the welcome page.
Done when: you see the Django rocket welcome page at localhost:8000.