The settings that matter
- Debug off, without exception, in production
- Allowed hosts set correctly
- Secret key from the environment, unique per environment
- Database credentials from the environment
- Secure cookie and HTTPS settings enabled
Debug left on in production exposes your settings, your database queries and your stack traces to anyone who triggers an error. It is the single most damaging misconfiguration.
Static and media files
- Static files collected and served by the web server or a CDN, not by Django
- Media uploads stored outside the code directory, ideally in object storage
- Correct cache headers on static assets
- Uploaded files never served from a path that could execute them
Migrations in the deployment
Migrations should run as a defined step in deployment, not manually afterwards. Manual migrations are forgotten, and a code version expecting a column that does not exist fails immediately.
Design them backwards-compatible where possible, so code can roll back without a database rollback.
The runtime stack
| Component | Role |
|---|---|
| Application server | Runs the Django code |
| Reverse proxy | TLS, static files, buffering |
| Process supervisor | Restarts anything that exits |
| Worker processes | Background tasks |
| Scheduler | Recurring work |
The development server should never run in production. It is single-threaded, unoptimised and explicitly not intended for it.
Health checks and logging
A health endpoint that checks the database and any critical dependency, so monitoring knows whether the application is actually working rather than merely running.
Logs to standard output, collected centrally. A log file on a server nobody reads is not logging.