Per-Environment Configuration

## What DEBUG is `DEBUG` is a boolean setting. Its default in `django/conf/global_settings.py` is `False`, but the `settings.py` that `startproject` generates sets `DEBUG = True` for convenience — which is how it ends up on in production when nobody changes it. Django's settings reference is blunt: "Never deploy a site into production with `DEBUG` turned on." ## What DEBUG=True turns on | Area | With `DEBUG = True` | |---|---| | unhandled exceptions | a technical 500 page with traceback, local variables, request data and settings | | 404 responses | a technical 404 page listing the URL patterns Django tried | | SQL | every query is recorded in `connection.queries` | | host checking | an empty `ALLOWED_HOSTS` allows `.localhost`, `127.0.0.1` and `[::1]` | | static files | `runserver` from `django.contrib.staticfiles` serves them | | templates | the Django engine's `debug` option defaults to `DEBUG`, adding error context | | logging | the default logging config prints `django` messages to the console | The debug page masks settings whose names look sensitive — the docs list partial matches such as `API`, `KEY`, `PASS`, `SECRET`, `SIGNATURE` and `TOKEN` — but it still exposes file paths, installed apps, middleware and other configuration an attacker can use. On a payroll service, a local variable in a traceback might be an employee's salary record. ## The query log in detail With debug on, database wrappers log each query. The log is reset when a request starts and is capped at 9,000 entries per connection, so a web process does not grow without bound — but long-running management commands or worker processes outside the request cycle keep filling it until the cap, and the logging itself costs time. It is a development aid, not something to pay for in production. ## What changes when DEBUG is False 1. **Plain error pages** — Django renders `404.html` and `500.html` templates if present, or minimal defaults. 2. **Error reporting** — the default logging config sends `django` errors to the `mail_admins` handler, which only runs with debug off and mails the addresses in `ADMINS` (empty by default). 3. **ALLOWED_HOSTS is enforced strictly** — an empty list no longer falls back to localhost, so every request fails. The settings reference says failing to set it results in all requests "being returned as Bad Request (400)". 4. **Static files are no longer served by `runserver`** unless you pass `--insecure`; production needs a real static-file setup. ## Setting it per environment For a payroll service with development, staging and production, `DEBUG` should come from the environment with a **safe default**: ```python import os DEBUG = os.environ.get("DJANGO_DEBUG", "") == "1" ALLOWED_HOSTS = [h for h in os.environ.get("DJANGO_ALLOWED_HOSTS", "").split(",") if h] ``` - Compare the string explicitly: `bool("False")` is `True`, so `bool(os.environ.get("DJANGO_DEBUG"))` turns debug on for any non-empty value. - `ALLOWED_HOSTS` must be a list or tuple; assigning the raw environment string raises `ImproperlyConfigured`. - Never change `DEBUG` at runtime; the docs say the only place to assign settings is a settings file. ## What an interviewer is listening for A junior candidate knows `DEBUG` shows tracebacks and must be off in production. A stronger one lists the other effects — query recording, localhost trust, static serving — and immediately adds that `ALLOWED_HOSTS` must be set when it is off, explaining the 400 errors that appear right after the switch.