Settings and Configuration

What every core, security, and strategy setting actually controls

SECRET_KEY signs everythingsessions, CSRF tokens, reset links
DEBUG = False in productionALLOWED_HOSTS must be set too
DATABASES needs a "default" keyDjango refuses to start without one
Secrets live in the environmentnever a settings.py literal

1.Routing, rendering, and auth settings

INSTALLED_APPS, MIDDLEWARE, ROOT_URLCONF, TEMPLATES, and DATABASES wire together which code runs and where data lives; AUTH_PASSWORD_VALIDATORS and AUTHENTICATION_BACKENDS control how a password is judged and how a login is checked.

Key features

INSTALLED_APPS has no default (empty list) — an app not listed here is invisible to migrate, admin, and the template loader
MIDDLEWARE order matters: request-phase runs top-to-bottom, response-phase runs bottom-to-top
ROOT_URLCONF names the dotted path to the module holding the top-level urlpatterns
DATABASES must define a "default" key at minimum — Django refuses to start without one
AUTH_PASSWORD_VALIDATORS is a list of validator classes checked in order when a user sets a password

Core routing, rendering, and auth settings

Core routing, rendering, and auth settings
Setting	Default	Configures
INSTALLED_APPS	[] (empty list)	which built-in and project apps the registry loads
MIDDLEWARE	None	the ordered chain every request/response passes through
ROOT_URLCONF	not set — required	dotted path to the module with urlpatterns
TEMPLATES	[] (empty list)	template engines, their dirs, and context processors
DATABASES	{} (empty dict)	database engine, name, host, and credentials — needs a "default" key
AUTH_PASSWORD_VALIDATORS	[] (empty list)	validator classes run in order when a password is set
AUTHENTICATION_BACKENDS	["...ModelBackend"]	the ordered list of backends authenticate() tries

Command

python

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.csrf.CsrfViewMiddleware",
    "django.contrib.auth.middleware.AuthenticationMiddleware",
]

INSTALLED_APPS/MIDDLEWARE/ROOT_URLCONF/TEMPLATES/DATABASES wire together what exists and where data lives; AUTH_PASSWORD_VALIDATORS and AUTHENTICATION_BACKENDS are both ordered lists tried in sequence.

2.Locale, static, and media settings

LANGUAGE_CODE/TIME_ZONE/USE_TZ control locale and datetime handling; STATIC_URL/STATIC_ROOT and MEDIA_URL/MEDIA_ROOT are two matching pairs — the URL prefix the browser sees, and the filesystem directory the files actually live in.

Key features

STATIC_ROOT is where `collectstatic` copies files TO — it does not exist until that command runs
MEDIA_ROOT is where uploaded FileField/ImageField content is actually written
STATIC_URL and MEDIA_URL are just strings used to build URLs in templates — they don't need to point at real filesystem paths
USE_TZ = True (default since Django 5.0) stores datetimes in UTC and converts to TIME_ZONE only for display
LANGUAGE_CODE picks the default locale (e.g. "en-us") used before any per-request override

Locale, static, and media settings

Locale, static, and media settings
Setting	Default	Configures
LANGUAGE_CODE	"en-us"	the default locale for translation and formatting
TIME_ZONE	"America/Chicago"	the zone datetimes are converted to for display
USE_TZ	True	whether datetimes are timezone-aware, stored in UTC
STATIC_URL	"static/"	URL prefix templates use to reference static files
STATIC_ROOT	None	filesystem directory collectstatic copies files into
MEDIA_URL	"" (empty)	URL prefix for user-uploaded files
MEDIA_ROOT	"" (empty)	filesystem directory FileField/ImageField writes to

Command

python

LANGUAGE_CODE = "en-us"
TIME_ZONE = "UTC"
USE_TZ = True

STATIC_ROOT/MEDIA_ROOT are real filesystem directories; STATIC_URL/MEDIA_URL are just the public URL prefixes that map to them — never serve MEDIA_ROOT from Django itself in production.

3.Cache, email, logging, and server settings

CACHES configures one or more named cache backends (default: in-process memory); EMAIL_BACKEND picks how mail is actually sent; LOGGING is a full dictConfig; ASGI_APPLICATION/WSGI_APPLICATION point servers at the project's entry-point callable.

Key features

CACHES defaults to LocMemCache — process-local, useless across multiple workers, fine for development only
EMAIL_BACKEND defaults to real SMTP — override to console/locmem in development to avoid sending real mail
LOGGING is a dictConfig-shaped dict — loggers, handlers, and formatters, same shape as Python's stdlib logging config
ASGI_APPLICATION and WSGI_APPLICATION both default to pointing at the generated asgi.py/wsgi.py "application" callable
Only one of ASGI_APPLICATION/WSGI_APPLICATION is actually used, depending on which kind of server runs the project

Cache, email, logging, and server settings

Cache, email, logging, and server settings
Setting	Default	Configures
CACHES	LocMemCache, in-process	one or more named cache backends (Redis, Memcached, ...)
EMAIL_BACKEND	SMTP backend	how send_mail() actually delivers — SMTP, console, locmem, file
LOGGING	Django's built-in config	loggers/handlers/formatters, a stdlib dictConfig-shaped dict
ASGI_APPLICATION	"<project>.asgi.application"	the ASGI callable an async-capable server calls
WSGI_APPLICATION	"<project>.wsgi.application"	the WSGI callable a synchronous server calls

Command

python

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {"console": {"class": "logging.StreamHandler"}},
    "root": {"handlers": ["console"], "level": "INFO"},
}

CACHES defaults to a per-process LocMemCache — switch to Redis/Memcached before running multiple workers; EMAIL_BACKEND and LOGGING are the other two settings worth overriding per environment.

Spotted a mistake on this page? Tell us.

Read Sheet