Preparing for Deployment
Turning Off DEBUG
Django's debug pages are extremely helpful during development because they show full stack traces, settings values, and SQL queries. In production, that same information handed to a stranger is a serious security risk, so DEBUG must be False.
Warning: Never deploy with DEBUG = True -- it exposes your settings and code to anyone who can trigger an error page.
Example: Turning Off DEBUG
Django's debug pages are extremely helpful during development because they show full stack traces, settings values, and SQL queries. In production, that same information handed to a stranger is a serious security risk, so DEBUG must be False.
# settings.py
import os
DEBUG = os.environ.get('DJANGO_DEBUG', 'False') == 'True'
ALLOWED_HOSTS = ['www.example.com', 'example.com']
{# Django-only code -- models.py/views.py/urls.py/settings.py
snippets, or template markup using Django template tags/variables
-- can't run standalone via Judge0 or the browser preview, since
it needs a real Django project. Only this course's pure-Python
examples (example_lang == 'python', no Django imports) are
actually runnable, so those still get the button below. #}
Collecting Static Files
During development, Django serves static files itself for convenience. In production, a dedicated web server (or cloud storage) serves them instead, so all static files first need to be gathered into one directory with collectstatic.
Note: Run collectstatic every time static files change before redeploying.
Example: Collecting Static Files
During development, Django serves static files itself for convenience. In production, a dedicated web server (or cloud storage) serves them instead, so all static files first need to be gathered into one directory with collectstatic.
python manage.py collectstatic --noinput
⚠️ Run this command in your terminal.
Checking Deployment Readiness
Django ships a built-in check specifically for production settings. Running it before deploying catches common misconfigurations like a weak SECRET_KEY or missing security headers.
Example: Checking Deployment Readiness
Django ships a built-in check specifically for production settings. Running it before deploying catches common misconfigurations like a weak SECRET_KEY or missing security headers.
python manage.py check --deploy
⚠️ Run this command in your terminal.
- Deploying with DEBUG = True, which leaks stack traces, settings, and file paths to anyone who triggers an error.
- Leaving ALLOWED_HOSTS empty or as ['*'] in production instead of listing the real domain.
- Forgetting to run collectstatic, so CSS/JS files 404 on the live site even though they worked locally.
- DEBUG must be set to False before deploying, since debug pages expose sensitive internal details.
- ALLOWED_HOSTS must list the exact domain(s) the site will be served from.
- Static files need to be collected into one folder with collectstatic so a web server can serve them.
- Secrets like SECRET_KEY and database passwords should come from environment variables, not hardcoded values.
Chapter Quiz — Complete all 9 topics to unlock
0/9 topics done
Complete these topics first: