Settings | Django documentation (original) (raw)

Core Settings

Here’s a list of settings available in Django core and their default values. Settings provided by contrib apps are listed below, followed by a topical index of the core settings. For introductory material, see the settings topic guide.

ABSOLUTE_URL_OVERRIDES

Default: {} (Empty dictionary)

A dictionary mapping "app_label.model_name" strings to functions that take a model object and return its URL. This is a way of inserting or overridingget_absolute_url() methods on a per-installation basis. Example:

ABSOLUTE_URL_OVERRIDES = { "blogs.blog": lambda o: "/blogs/%s/" % o.slug, "news.story": lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug), }

The model name used in this setting should be all lowercase, regardless of the case of the actual model class name.

ADMINS

Default: [] (Empty list)

A list of all the people who get code error notifications. WhenDEBUG=False and AdminEmailHandleris configured in LOGGING (done by default), Django emails these people the details of exceptions raised in the request/response cycle.

Each item in the list should be a tuple of (Full name, email address). Example:

[("John", "john@example.com"), ("Mary", "mary@example.com")]

ALLOWED_HOSTS

Default: [] (Empty list)

A list of strings representing the host/domain names that this Django site can serve. This is a security measure to prevent HTTP Host header attacks, which are possible even under many seemingly-safe web server configurations.

Values in this list can be fully qualified names (e.g. 'www.example.com'), in which case they will be matched against the request’s Host header exactly (case-insensitive, not including port). A value beginning with a period can be used as a subdomain wildcard: '.example.com' will matchexample.com, www.example.com, and any other subdomain ofexample.com. A value of '*' will match anything; in this case you are responsible to provide your own validation of the Host header (perhaps in a middleware; if so this middleware must be listed first inMIDDLEWARE).

Django also allows the fully qualified domain name (FQDN) of any entries. Some browsers include a trailing dot in the Host header which Django strips when performing host validation.

If the Host header (or X-Forwarded-Host ifUSE_X_FORWARDED_HOST is enabled) does not match any value in this list, the django.http.HttpRequest.get_host() method will raiseSuspiciousOperation.

When DEBUG is True and ALLOWED_HOSTS is empty, the host is validated against ['.localhost', '127.0.0.1', '[::1]'].

ALLOWED_HOSTS is also checked when running tests.

This validation only applies via get_host(); if your code accesses the Host header directly from request.META you are bypassing this security protection.

APPEND_SLASH

Default: True

When set to True, if the request URL does not match any of the patterns in the URLconf and it doesn’t end in a slash, an HTTP redirect is issued to the same URL with a slash appended. Note that the redirect may cause any data submitted in a POST request to be lost.

The APPEND_SLASH setting is only used ifCommonMiddleware is installed (see Middleware). See also PREPEND_WWW.

CACHES

Default:

{ "default": { "BACKEND": "django.core.cache.backends.locmem.LocMemCache", } }

A dictionary containing the settings for all caches to be used with Django. It is a nested dictionary whose contents maps cache aliases to a dictionary containing the options for an individual cache.

The CACHES setting must configure a default cache; any number of additional caches may also be specified. If you are using a cache backend other than the local memory cache, or you need to define multiple caches, other options will be required. The following cache options are available.

BACKEND

Default: '' (Empty string)

The cache backend to use. The built-in cache backends are:

You can use a cache backend that doesn’t ship with Django by settingBACKEND to a fully-qualified path of a cache backend class (i.e. mypackage.backends.whatever.WhateverCache).

KEY_FUNCTION

A string containing a dotted path to a function (or any callable) that defines how to compose a prefix, version and key into a final cache key. The default implementation is equivalent to the function:

def make_key(key, key_prefix, version): return ":".join([key_prefix, str(version), key])

You may use any key function you want, as long as it has the same argument signature.

See the cache documentation for more information.

KEY_PREFIX

Default: '' (Empty string)

A string that will be automatically included (prepended by default) to all cache keys used by the Django server.

See the cache documentation for more information.

LOCATION

Default: '' (Empty string)

The location of the cache to use. This might be the directory for a file system cache, a host and port for a memcache server, or an identifying name for a local memory cache. e.g.:

CACHES = { "default": { "BACKEND": "django.core.cache.backends.filebased.FileBasedCache", "LOCATION": "/var/tmp/django_cache", } }

OPTIONS

Default: None

Extra parameters to pass to the cache backend. Available parameters vary depending on your cache backend.

Some information on available parameters can be found in thecache arguments documentation. For more information, consult your backend module’s own documentation.

TIMEOUT

Default: 300

The number of seconds before a cache entry is considered stale. If the value of this setting is None, cache entries will not expire. A value of 0causes keys to immediately expire (effectively “don’t cache”).

VERSION

Default: 1

The default version number for cache keys generated by the Django server.

See the cache documentation for more information.

CACHE_MIDDLEWARE_ALIAS

Default: 'default'

The cache connection to use for the cache middleware.

CACHE_MIDDLEWARE_KEY_PREFIX

Default: '' (Empty string)

A string which will be prefixed to the cache keys generated by the cache middleware. This prefix is combined with theKEY_PREFIX setting; it does not replace it.

See Django’s cache framework.

CACHE_MIDDLEWARE_SECONDS

Default: 600

The default integer number of seconds to cache a page for thecache middleware.

See Django’s cache framework.

Default: 31449600 (approximately 1 year, in seconds)

The age of CSRF cookies, in seconds.

The reason for setting a long-lived expiration time is to avoid problems in the case of a user closing a browser or bookmarking a page and then loading that page from a browser cache. Without persistent cookies, the form submission would fail in this case.

Some browsers (specifically Internet Explorer) can disallow the use of persistent cookies or can have the indexes to the cookie jar corrupted on disk, thereby causing CSRF protection checks to (sometimes intermittently) fail. Change this setting to None to use session-based CSRF cookies, which keep the cookies in-memory instead of on persistent storage.

Default: None

The domain to be used when setting the CSRF cookie. This can be useful for easily allowing cross-subdomain requests to be excluded from the normal cross site request forgery protection. It should be set to a string such as".example.com" to allow a POST request from a form on one subdomain to be accepted by a view served from another subdomain.

Please note that the presence of this setting does not imply that Django’s CSRF protection is safe from cross-subdomain attacks by default - please see theCSRF limitations section.

Default: False

Whether to use HttpOnly flag on the CSRF cookie. If this is set toTrue, client-side JavaScript will not be able to access the CSRF cookie.

Designating the CSRF cookie as HttpOnly doesn’t offer any practical protection because CSRF is only to protect against cross-domain attacks. If an attacker can read the cookie via JavaScript, they’re already on the same domain as far as the browser knows, so they can do anything they like anyway. (XSS is a much bigger hole than CSRF.)

Although the setting offers little practical benefit, it’s sometimes required by security auditors.

If you enable this and need to send the value of the CSRF token with an AJAX request, your JavaScript must pull the value from a hidden CSRF token form input instead of from the cookie.

See SESSION_COOKIE_HTTPONLY for details on HttpOnly.

Default: 'csrftoken'

The name of the cookie to use for the CSRF authentication token. This can be whatever you want (as long as it’s different from the other cookie names in your application). See Cross Site Request Forgery protection.

Default: '/'

The path set on the CSRF cookie. This should either match the URL path of your Django installation or be a parent of that path.

This is useful if you have multiple Django instances running under the same hostname. They can use different cookie paths, and each instance will only see its own CSRF cookie.

Default: 'Lax'

The value of the SameSite flag on the CSRF cookie. This flag prevents the cookie from being sent in cross-site requests.

See SESSION_COOKIE_SAMESITE for details about SameSite.

Default: False

Whether to use a secure cookie for the CSRF cookie. If this is set to True, the cookie will be marked as “secure”, which means browsers may ensure that the cookie is only sent with an HTTPS connection.

CSRF_USE_SESSIONS

Default: False

Whether to store the CSRF token in the user’s session instead of in a cookie. It requires the use of django.contrib.sessions.

Storing the CSRF token in a cookie (Django’s default) is safe, but storing it in the session is common practice in other web frameworks and therefore sometimes demanded by security auditors.

Since the default error views require the CSRF token,SessionMiddleware must appear inMIDDLEWARE before any middleware that may raise an exception to trigger an error view (such as PermissionDenied) if you’re using CSRF_USE_SESSIONS. See Middleware ordering.

CSRF_FAILURE_VIEW

Default: 'django.views.csrf.csrf_failure'

A dotted path to the view function to be used when an incoming request is rejected by the CSRF protection. The function should have this signature:

def csrf_failure(request, reason=""): ...

where reason is a short message (intended for developers or logging, not for end users) indicating the reason the request was rejected. It should return an HttpResponseForbidden.

django.views.csrf.csrf_failure() accepts an additional template_nameparameter that defaults to '403_csrf.html'. If a template with that name exists, it will be used to render the page.

CSRF_HEADER_NAME

Default: 'HTTP_X_CSRFTOKEN'

The name of the request header used for CSRF authentication.

As with other HTTP headers in request.META, the header name received from the server is normalized by converting all characters to uppercase, replacing any hyphens with underscores, and adding an 'HTTP_' prefix to the name. For example, if your client sends a 'X-XSRF-TOKEN' header, the setting should be 'HTTP_X_XSRF_TOKEN'.

CSRF_TRUSTED_ORIGINS

Default: [] (Empty list)

A list of trusted origins for unsafe requests (e.g. POST).

For requests that include the Origin header, Django’s CSRF protection requires that header match the origin present in the Host header.

For a secure unsafe request that doesn’t include the Origin header, the request must have aReferer header that matches the origin present in the Host header.

These checks prevent, for example, a POST request fromsubdomain.example.com from succeeding against api.example.com. If you need cross-origin unsafe requests, continuing the example, add'https://subdomain.example.com' to this list (and/or http://... if requests originate from an insecure page).

The setting also supports subdomains, so you could add'https://*.example.com', for example, to allow access from all subdomains of example.com.

DATABASES

Default: {} (Empty dictionary)

A dictionary containing the settings for all databases to be used with Django. It is a nested dictionary whose contents map a database alias to a dictionary containing the options for an individual database.

The DATABASES setting must configure a default database; any number of additional databases may also be specified.

The simplest possible settings file is for a single-database setup using SQLite. This can be configured using the following:

DATABASES = { "default": { "ENGINE": "django.db.backends.sqlite3", "NAME": "mydatabase", } }

When connecting to other database backends, such as MariaDB, MySQL, Oracle, or PostgreSQL, additional connection parameters will be required. See the ENGINE setting below on how to specify other database types. This example is for PostgreSQL:

DATABASES = { "default": { "ENGINE": "django.db.backends.postgresql", "NAME": "mydatabase", "USER": "mydatabaseuser", "PASSWORD": "mypassword", "HOST": "127.0.0.1", "PORT": "5432", } }

The following inner options that may be required for more complex configurations are available:

ATOMIC_REQUESTS

Default: False

Set this to True to wrap each view in a transaction on this database. SeeTying transactions to HTTP requests.

AUTOCOMMIT

Default: True

Set this to False if you want to disable Django’s transaction management and implement your own.

ENGINE

Default: '' (Empty string)

The database backend to use. The built-in database backends are:

You can use a database backend that doesn’t ship with Django by settingENGINE to a fully-qualified path (i.e. mypackage.backends.whatever).

HOST

Default: '' (Empty string)

Which host to use when connecting to the database. An empty string means localhost. Not used with SQLite.

If this value starts with a forward slash ('/') and you’re using MySQL, MySQL will connect via a Unix socket to the specified socket. For example:

If you’re using MySQL and this value doesn’t start with a forward slash, then this value is assumed to be the host.

If you’re using PostgreSQL, by default (empty HOST), the connection to the database is done through UNIX domain sockets (‘local’ lines inpg_hba.conf). If your UNIX domain socket is not in the standard location, use the same value of unix_socket_directory from postgresql.conf. If you want to connect through TCP sockets, set HOST to ‘localhost’ or ‘127.0.0.1’ (‘host’ lines in pg_hba.conf). On Windows, you should always define HOST, as UNIX domain sockets are not available.

NAME

Default: '' (Empty string)

The name of the database to use. For SQLite, it’s the full path to the database file. When specifying the path, always use forward slashes, even on Windows (e.g. C:/homes/user/mysite/sqlite3.db).

CONN_MAX_AGE

Default: 0

The lifetime of a database connection, as an integer of seconds. Use 0 to close database connections at the end of each request — Django’s historical behavior — and None for unlimited persistent database connections.

CONN_HEALTH_CHECKS

Default: False

If set to True, existing persistent database connections will be health checked before they are reused in each request performing database access. If the health check fails, the connection will be reestablished without failing the request when the connection is no longer usable but the database server is ready to accept and serve new connections (e.g. after database server restart closing existing connections).

OPTIONS

Default: {} (Empty dictionary)

Extra parameters to use when connecting to the database. Available parameters vary depending on your database backend.

Some information on available parameters can be found in theDatabase Backends documentation. For more information, consult your backend module’s own documentation.

PASSWORD

Default: '' (Empty string)

The password to use when connecting to the database. Not used with SQLite.

PORT

Default: '' (Empty string)

The port to use when connecting to the database. An empty string means the default port. Not used with SQLite.

TIME_ZONE

Default: None

A string representing the time zone for this database connection or None. This inner option of the DATABASES setting accepts the same values as the general TIME_ZONE setting.

When USE_TZ is True, reading datetimes from the database returns aware datetimes with the timezone set to this option’s value if notNone, or to UTC otherwise.

When USE_TZ is False, it is an error to set this option.

DISABLE_SERVER_SIDE_CURSORS

Default: False

Set this to True if you want to disable the use of server-side cursors withQuerySet.iterator(). Transaction pooling and server-side cursorsdescribes the use case.

This is a PostgreSQL-specific setting.

USER

Default: '' (Empty string)

The username to use when connecting to the database. Not used with SQLite.

TEST

Default: {} (Empty dictionary)

A dictionary of settings for test databases; for more details about the creation and use of test databases, see The test database.

Here’s an example with a test database configuration:

DATABASES = { "default": { "ENGINE": "django.db.backends.postgresql", "USER": "mydatabaseuser", "NAME": "mydatabase", "TEST": { "NAME": "mytestdatabase", }, }, }

The following keys in the TEST dictionary are available:

CHARSET

Default: None

The character set encoding used to create the test database. The value of this string is passed directly through to the database, so its format is backend-specific.

Supported by the PostgreSQL (postgresql) and MySQL (mysql) backends.

COLLATION

Default: None

The collation order to use when creating the test database. This value is passed directly to the backend, so its format is backend-specific.

Only supported for the mysql backend (see the MySQL manual for details).

DEPENDENCIES

Default: ['default'], for all databases other than default, which has no dependencies.

The creation-order dependencies of the database. See the documentation on controlling the creation order of test databases for details.

MIGRATE

Default: True

When set to False, migrations won’t run when creating the test database. This is similar to setting None as a value in MIGRATION_MODULES, but for all apps.

MIRROR

Default: None

The alias of the database that this database should mirror during testing. It depends on transactions and therefore must be used withinTransactionTestCase instead ofTestCase.

This setting exists to allow for testing of primary/replica (referred to as master/slave by some databases) configurations of multiple databases. See the documentation ontesting primary/replica configurations for details.

NAME

Default: None

The name of database to use when running the test suite.

If the default value (None) is used with the SQLite database engine, the tests will use a memory resident database. For all other database engines the test database will use the name 'test_' + DATABASE_NAME.

See The test database.

TEMPLATE

This is a PostgreSQL-specific setting.

The name of a template (e.g. 'template0') from which to create the test database.

CREATE_DB

Default: True

This is an Oracle-specific setting.

If it is set to False, the test tablespaces won’t be automatically created at the beginning of the tests or dropped at the end.

CREATE_USER

Default: True

This is an Oracle-specific setting.

If it is set to False, the test user won’t be automatically created at the beginning of the tests and dropped at the end.

USER

Default: None

This is an Oracle-specific setting.

The username to use when connecting to the Oracle database that will be used when running tests. If not provided, Django will use 'test_' + USER.

PASSWORD

Default: None

This is an Oracle-specific setting.

The password to use when connecting to the Oracle database that will be used when running tests. If not provided, Django will generate a random password.

ORACLE_MANAGED_FILES

Default: False

This is an Oracle-specific setting.

If set to True, Oracle Managed Files (OMF) tablespaces will be used.DATAFILE and DATAFILE_TMP will be ignored.

TBLSPACE

Default: None

This is an Oracle-specific setting.

The name of the tablespace that will be used when running tests. If not provided, Django will use 'test_' + USER.

TBLSPACE_TMP

Default: None

This is an Oracle-specific setting.

The name of the temporary tablespace that will be used when running tests. If not provided, Django will use 'test_' + USER + '_temp'.

DATAFILE

Default: None

This is an Oracle-specific setting.

The name of the datafile to use for the TBLSPACE. If not provided, Django will use TBLSPACE + '.dbf'.

DATAFILE_TMP

Default: None

This is an Oracle-specific setting.

The name of the datafile to use for the TBLSPACE_TMP. If not provided, Django will use TBLSPACE_TMP + '.dbf'.

DATAFILE_MAXSIZE

Default: '500M'

This is an Oracle-specific setting.

The maximum size that the DATAFILE is allowed to grow to.

DATAFILE_TMP_MAXSIZE

Default: '500M'

This is an Oracle-specific setting.

The maximum size that the DATAFILE_TMP is allowed to grow to.

DATAFILE_SIZE

Default: '50M'

This is an Oracle-specific setting.

The initial size of the DATAFILE.

DATAFILE_TMP_SIZE

Default: '50M'

This is an Oracle-specific setting.

The initial size of the DATAFILE_TMP.

DATAFILE_EXTSIZE

Default: '25M'

This is an Oracle-specific setting.

The amount by which the DATAFILE is extended when more space is required.

DATAFILE_TMP_EXTSIZE

Default: '25M'

This is an Oracle-specific setting.

The amount by which the DATAFILE_TMP is extended when more space is required.

DATA_UPLOAD_MAX_MEMORY_SIZE

Default: 2621440 (i.e. 2.5 MB).

The maximum size in bytes that a request body may be before aSuspiciousOperation (RequestDataTooBig) is raised. The check is done when accessing request.body or request.POSTand is calculated against the total request size excluding any file upload data. You can set this to None to disable the check. Applications that are expected to receive unusually large form posts should tune this setting.

The amount of request data is correlated to the amount of memory needed to process the request and populate the GET and POST dictionaries. Large requests could be used as a denial-of-service attack vector if left unchecked. Since web servers don’t typically perform deep request inspection, it’s not possible to perform a similar check at that level.

See also FILE_UPLOAD_MAX_MEMORY_SIZE.

DATA_UPLOAD_MAX_NUMBER_FIELDS

Default: 1000

The maximum number of parameters that may be received via GET or POST before aSuspiciousOperation (TooManyFields) is raised. You can set this to None to disable the check. Applications that are expected to receive an unusually large number of form fields should tune this setting.

The number of request parameters is correlated to the amount of time needed to process the request and populate the GET and POST dictionaries. Large requests could be used as a denial-of-service attack vector if left unchecked. Since web servers don’t typically perform deep request inspection, it’s not possible to perform a similar check at that level.

DATA_UPLOAD_MAX_NUMBER_FILES

Default: 100

The maximum number of files that may be received via POST in amultipart/form-data encoded request before aSuspiciousOperation (TooManyFiles) is raised. You can set this to None to disable the check. Applications that are expected to receive an unusually large number of file fields should tune this setting.

The number of accepted files is correlated to the amount of time and memory needed to process the request. Large requests could be used as a denial-of-service attack vector if left unchecked. Since web servers don’t typically perform deep request inspection, it’s not possible to perform a similar check at that level.

DATABASE_ROUTERS

Default: [] (Empty list)

The list of routers that will be used to determine which database to use when performing a database query.

See the documentation on automatic database routing in multi database configurations.

DATE_FORMAT

Default: 'N j, Y' (e.g. Feb. 4, 2003)

The default formatting to use for displaying date fields in any part of the system. Note that the locale-dictated format has higher precedence and will be applied instead. See allowed date format strings.

See also DATETIME_FORMAT, TIME_FORMAT and SHORT_DATE_FORMAT.

DATE_INPUT_FORMATS

Default:

[ "%Y-%m-%d", # '2006-10-25' "%m/%d/%Y", # '10/25/2006' "%m/%d/%y", # '10/25/06' "%b %d %Y", # 'Oct 25 2006' "%b %d, %Y", # 'Oct 25, 2006' "%d %b %Y", # '25 Oct 2006' "%d %b, %Y", # '25 Oct, 2006' "%B %d %Y", # 'October 25 2006' "%B %d, %Y", # 'October 25, 2006' "%d %B %Y", # '25 October 2006' "%d %B, %Y", # '25 October, 2006' ]

A list of formats that will be accepted when inputting data on a date field. Formats will be tried in order, using the first valid one. Note that these format strings use Python’s datetime module syntax, not the format strings from the datetemplate filter.

The locale-dictated format has higher precedence and will be applied instead.

See also DATETIME_INPUT_FORMATS and TIME_INPUT_FORMATS.

DATETIME_FORMAT

Default: 'N j, Y, P' (e.g. Feb. 4, 2003, 4 p.m.)

The default formatting to use for displaying datetime fields in any part of the system. Note that the locale-dictated format has higher precedence and will be applied instead. See allowed date format strings.

See also DATE_FORMAT, TIME_FORMAT and SHORT_DATETIME_FORMAT.

DATETIME_INPUT_FORMATS

Default:

[ "%Y-%m-%d %H:%M:%S", # '2006-10-25 14:30:59' "%Y-%m-%d %H:%M:%S.%f", # '2006-10-25 14:30:59.000200' "%Y-%m-%d %H:%M", # '2006-10-25 14:30' "%m/%d/%Y %H:%M:%S", # '10/25/2006 14:30:59' "%m/%d/%Y %H:%M:%S.%f", # '10/25/2006 14:30:59.000200' "%m/%d/%Y %H:%M", # '10/25/2006 14:30' "%m/%d/%y %H:%M:%S", # '10/25/06 14:30:59' "%m/%d/%y %H:%M:%S.%f", # '10/25/06 14:30:59.000200' "%m/%d/%y %H:%M", # '10/25/06 14:30' ]

A list of formats that will be accepted when inputting data on a datetime field. Formats will be tried in order, using the first valid one. Note that these format strings use Python’s datetime module syntax, not the format strings from the datetemplate filter. Date-only formats are not included as datetime fields will automatically try DATE_INPUT_FORMATS in last resort.

The locale-dictated format has higher precedence and will be applied instead.

See also DATE_INPUT_FORMATS and TIME_INPUT_FORMATS.

DEBUG

Default: False

A boolean that turns on/off debug mode.

Never deploy a site into production with DEBUG turned on.

One of the main features of debug mode is the display of detailed error pages. If your app raises an exception when DEBUG is True, Django will display a detailed traceback, including a lot of metadata about your environment, such as all the currently defined Django settings (fromsettings.py).

As a security measure, Django will not include settings that might be sensitive, such as SECRET_KEY. Specifically, it will exclude any setting whose name includes any of the following:

Note that these are partial matches. 'PASS' will also match PASSWORD, just as 'TOKEN' will also match TOKENIZED and so on.

Still, note that there are always going to be sections of your debug output that are inappropriate for public consumption. File paths, configuration options and the like all give attackers extra information about your server.

It is also important to remember that when running with DEBUGturned on, Django will remember every SQL query it executes. This is useful when you’re debugging, but it’ll rapidly consume memory on a production server.

Finally, if DEBUG is False, you also need to properly set the ALLOWED_HOSTS setting. Failing to do so will result in all requests being returned as “Bad Request (400)”.

DEBUG_PROPAGATE_EXCEPTIONS

Default: False

If set to True, Django’s exception handling of view functions (handler500, or the debug view if DEBUGis True) and logging of 500 responses (django.request) is skipped and exceptions propagate upward.

This can be useful for some test setups. It shouldn’t be used on a live site unless you want your web server (instead of Django) to generate “Internal Server Error” responses. In that case, make sure your server doesn’t show the stack trace or other sensitive information in the response.

DECIMAL_SEPARATOR

Default: '.' (Dot)

Default decimal separator used when formatting decimal numbers.

Note that the locale-dictated format has higher precedence and will be applied instead.

See also NUMBER_GROUPING, THOUSAND_SEPARATOR andUSE_THOUSAND_SEPARATOR.

DEFAULT_AUTO_FIELD

Default: 'django.db.models.AutoField'

Default primary key field type to use for models that don’t have a field withprimary_key=True.

Migrating auto-created through tables

The value of DEFAULT_AUTO_FIELD will be respected when creating new auto-created through tables for many-to-many relationships.

Unfortunately, the primary keys of existing auto-created through tables cannot currently be updated by the migrations framework.

This means that if you switch the value of DEFAULT_AUTO_FIELD and then generate migrations, the primary keys of the related models will be updated, as will the foreign keys from the through table, but the primary key of the auto-created through table will not be migrated.

In order to address this, you should add aRunSQL operation to your migrations to perform the required ALTER TABLE step. You can check the existing table name through sqlmigrate, dbshell, or with the field’s remote_field.through._meta.db_table property.

Explicitly defined through models are already handled by the migrations system.

Allowing automatic migrations for the primary key of existing auto-created through tables may be implemented at a later date.

DEFAULT_CHARSET

Default: 'utf-8'

Default charset to use for all HttpResponse objects, if a MIME type isn’t manually specified. Used when constructing the Content-Type header.

DEFAULT_EXCEPTION_REPORTER

Default: 'django.views.debug.ExceptionReporter'

Default exception reporter class to be used if none has been assigned to theHttpRequest instance yet. SeeCustom error reports.

DEFAULT_EXCEPTION_REPORTER_FILTER

Default: 'django.views.debug.SafeExceptionReporterFilter'

Default exception reporter filter class to be used if none has been assigned to the HttpRequest instance yet. See Filtering error reports.

DEFAULT_FROM_EMAIL

Default: 'webmaster@localhost'

Default email address for automated correspondence from the site manager(s). This address is used in the From: header of outgoing emails and can take any format valid in the chosen email sending protocol.

This doesn’t affect error messages sent to ADMINS andMANAGERS. See SERVER_EMAIL for that.

DEFAULT_INDEX_TABLESPACE

Default: '' (Empty string)

Default tablespace to use for indexes on fields that don’t specify one, if the backend supports it (see Tablespaces).

DEFAULT_TABLESPACE

Default: '' (Empty string)

Default tablespace to use for models that don’t specify one, if the backend supports it (see Tablespaces).

DISALLOWED_USER_AGENTS

Default: [] (Empty list)

List of compiled regular expression objects representing User-Agent strings that are not allowed to visit any page, systemwide. Use this for bots/crawlers. This is only used if CommonMiddleware is installed (seeMiddleware).

EMAIL_BACKEND

Default: 'django.core.mail.backends.smtp.EmailBackend'

The backend to use for sending emails. For the list of available backends seeEmail backends.

EMAIL_FILE_PATH

Default: Not defined

The directory used by the file email backendto store output files.

EMAIL_HOST

Default: 'localhost'

The host to use for sending email.

See also EMAIL_PORT.

EMAIL_HOST_PASSWORD

Default: '' (Empty string)

Password to use for the SMTP server defined in EMAIL_HOST. This setting is used in conjunction with EMAIL_HOST_USER when authenticating to the SMTP server. If either of these settings is empty, Django won’t attempt authentication.

See also EMAIL_HOST_USER.

EMAIL_HOST_USER

Default: '' (Empty string)

Username to use for the SMTP server defined in EMAIL_HOST. If empty, Django won’t attempt authentication.

See also EMAIL_HOST_PASSWORD.

EMAIL_PORT

Default: 25

Port to use for the SMTP server defined in EMAIL_HOST.

EMAIL_SUBJECT_PREFIX

Default: '[Django] '

Subject-line prefix for email messages sent with django.core.mail.mail_adminsor django.core.mail.mail_managers. You’ll probably want to include the trailing space.

EMAIL_USE_LOCALTIME

Default: False

Whether to send the SMTP Date header of email messages in the local time zone (True) or in UTC (False).

EMAIL_USE_TLS

Default: False

Whether to use a TLS (secure) connection when talking to the SMTP server. This is used for explicit TLS connections, generally on port 587. If you are experiencing hanging connections, see the implicit TLS settingEMAIL_USE_SSL.

EMAIL_USE_SSL

Default: False

Whether to use an implicit TLS (secure) connection when talking to the SMTP server. In most email documentation this type of TLS connection is referred to as SSL. It is generally used on port 465. If you are experiencing problems, see the explicit TLS setting EMAIL_USE_TLS.

Note that EMAIL_USE_TLS/EMAIL_USE_SSL are mutually exclusive, so only set one of those settings to True.

EMAIL_SSL_CERTFILE

Default: None

If EMAIL_USE_SSL or EMAIL_USE_TLS is True and the secure connection to the SMTP server requires client authentication, use this setting to specify the path to a PEM-formatted certificate chain file, which must be used in conjunction with EMAIL_SSL_KEYFILE.

EMAIL_SSL_CERTFILE should not be used with a self-signed server certificate or a certificate from a private certificate authority (CA). In such cases, the server’s certificate (or the root certificate of the private CA) should be installed into the system’s CA bundle. This can be done by following platform-specific instructions for installing a root CA certificate, or by using OpenSSL’s SSL_CERT_FILE or SSL_CERT_DIR environment variables to specify a custom certificate bundle (if modifying the system bundle is not possible or desired).

For more complex scenarios, the SMTPEmailBackend can be subclassed to add root certificates to its ssl_context usingssl.SSLContext.load_verify_locations().

EMAIL_SSL_KEYFILE

Default: None

If EMAIL_USE_SSL or EMAIL_USE_TLS is True, you can optionally specify the path to a PEM-formatted private key file for client authentication of the SSL connection along with EMAIL_SSL_CERTFILE.

Note that setting EMAIL_SSL_CERTFILE and EMAIL_SSL_KEYFILEdoesn’t result in any certificate checking. They’re passed to the underlying SSL connection. Please refer to the documentation of Python’sssl.SSLContext.wrap_socket() function for details on how the certificate chain file and private key file are handled.

EMAIL_TIMEOUT

Default: None

Specifies a timeout in seconds for blocking operations like the connection attempt.

FILE_UPLOAD_HANDLERS

Default:

[ "django.core.files.uploadhandler.MemoryFileUploadHandler", "django.core.files.uploadhandler.TemporaryFileUploadHandler", ]

A list of handlers to use for uploading. Changing this setting allows complete customization – even replacement – of Django’s upload process.

See Managing files for details.

FILE_UPLOAD_MAX_MEMORY_SIZE

Default: 2621440 (i.e. 2.5 MB).

The maximum size (in bytes) that an upload will be before it gets streamed to the file system. See Managing files for details.

See also DATA_UPLOAD_MAX_MEMORY_SIZE.

FILE_UPLOAD_DIRECTORY_PERMISSIONS

Default: None

The numeric mode to apply to directories created in the process of uploading files.

This setting also determines the default permissions for collected static directories when using the collectstatic management command. Seecollectstatic for details on overriding it.

This value mirrors the functionality and caveats of theFILE_UPLOAD_PERMISSIONS setting.

FILE_UPLOAD_PERMISSIONS

Default: 0o644

The numeric mode (i.e. 0o644) to set newly uploaded files to. For more information about what these modes mean, see the documentation foros.chmod().

If None, you’ll get operating-system dependent behavior. On most platforms, temporary files will have a mode of 0o600, and files saved from memory will be saved using the system’s standard umask.

For security reasons, these permissions aren’t applied to the temporary files that are stored in FILE_UPLOAD_TEMP_DIR.

This setting also determines the default permissions for collected static files when using the collectstatic management command. Seecollectstatic for details on overriding it.

Warning

Always prefix the mode with 0o .

If you’re not familiar with file modes, please note that the 0o prefix is very important: it indicates an octal number, which is the way that modes must be specified. If you try to use 644, you’ll get totally incorrect behavior.

FILE_UPLOAD_TEMP_DIR

Default: None

The directory to store data to (typically files larger thanFILE_UPLOAD_MAX_MEMORY_SIZE) temporarily while uploading files. If None, Django will use the standard temporary directory for the operating system. For example, this will default to /tmp on *nix-style operating systems.

See Managing files for details.

FIRST_DAY_OF_WEEK

Default: 0 (Sunday)

A number representing the first day of the week. This is especially useful when displaying a calendar. This value is only used when not using format internationalization, or when a format cannot be found for the current locale.

The value must be an integer from 0 to 6, where 0 means Sunday, 1 means Monday and so on.

FIXTURE_DIRS

Default: [] (Empty list)

List of directories searched for fixture files, in addition to the fixtures directory of each application, in search order.

Note that these paths should use Unix-style forward slashes, even on Windows.

See Provide data with fixtures and Fixture loading.

FORCE_SCRIPT_NAME

Default: None

If not None, this will be used as the value of the SCRIPT_NAMEenvironment variable in any HTTP request. This setting can be used to override the server-provided value of SCRIPT_NAME, which may be a rewritten version of the preferred value or not supplied at all. It is also used bydjango.setup() to set the URL resolver script prefix outside of the request/response cycle (e.g. in management commands and standalone scripts) to generate correct URLs when FORCE_SCRIPT_NAME is provided.

FORM_RENDERER

Default: 'django.forms.renderers.DjangoTemplates'

The class that renders forms and form widgets. It must implementthe low-level render API. Included form renderers are:

FORMS_URLFIELD_ASSUME_HTTPS

Deprecated since version 5.0.

Default: False

Set this transitional setting to True to opt into using "https" as the new default value of URLField.assume_scheme during the Django 5.x release cycle.

FORMAT_MODULE_PATH

Default: None

A full Python path to a Python package that contains custom format definitions for project locales. If not None, Django will check for a formats.pyfile, under the directory named as the current locale, and will use the formats defined in this file.

The name of the directory containing the format definitions is expected to be named using locale name notation, for example de, pt_BR,en_US, etc.

For example, if FORMAT_MODULE_PATH is set to mysite.formats, and current language is en (English), Django will expect a directory tree like:

mysite/ formats/ init.py en/ init.py formats.py

You can also set this setting to a list of Python paths, for example:

FORMAT_MODULE_PATH = [ "mysite.formats", "some_app.formats", ]

When Django searches for a certain format, it will go through all given Python paths until it finds a module that actually defines the given format. This means that formats defined in packages farther up in the list will take precedence over the same formats in packages farther down.

Available formats are:

IGNORABLE_404_URLS

Default: [] (Empty list)

List of compiled regular expression objects describing URLs that should be ignored when reporting HTTP 404 errors via email (seeHow to manage error reporting). Regular expressions are matched againstrequest's full paths (including query string, if any). Use this if your site does not provide a commonly requested file such as favicon.ico or robots.txt.

This is only used ifBrokenLinkEmailsMiddleware is enabled (seeMiddleware).

INSTALLED_APPS

Default: [] (Empty list)

A list of strings designating all applications that are enabled in this Django installation. Each string should be a dotted Python path to:

Learn more about application configurations.

Use the application registry for introspection

Your code should never access INSTALLED_APPS directly. Usedjango.apps.apps instead.

Application names and labels must be unique inINSTALLED_APPS

Application names — the dotted Python path to the application package — must be unique. There is no way to include the same application twice, short of duplicating its code under another name.

Application labels — by default the final part of the name — must be unique too. For example, you can’t include both django.contrib.auth and myproject.auth. However, you can relabel an application with a custom configuration that defines a different label.

These rules apply regardless of whether INSTALLED_APPSreferences application configuration classes or application packages.

When several applications provide different versions of the same resource (template, static file, management command, translation), the application listed first in INSTALLED_APPS has precedence.

INTERNAL_IPS

Default: [] (Empty list)

A list of IP addresses, as strings, that:

LANGUAGE_CODE

Default: 'en-us'

A string representing the language code for this installation. This should be in standard language ID format. For example, U.S. English is "en-us". See also the list of language identifiers andInternationalization and localization.

It serves three purposes:

See How Django discovers language preference for more details.

Default: None (expires at browser close)

The age of the language cookie, in seconds.

Default: None

The domain to use for the language cookie. Set this to a string such as"example.com" for cross-domain cookies, or use None for a standard domain cookie.

Be cautious when updating this setting on a production site. If you update this setting to enable cross-domain cookies on a site that previously used standard domain cookies, existing user cookies that have the old domain will not be updated. This will result in site users being unable to switch the language as long as these cookies persist. The only safe and reliable option to perform the switch is to change the language cookie name permanently (via the LANGUAGE_COOKIE_NAME setting) and to add a middleware that copies the value from the old cookie to a new one and then deletes the old one.

Default: False

Whether to use HttpOnly flag on the language cookie. If this is set toTrue, client-side JavaScript will not be able to access the language cookie.

See SESSION_COOKIE_HTTPONLY for details on HttpOnly.

Default: 'django_language'

The name of the cookie to use for the language cookie. This can be whatever you want (as long as it’s different from the other cookie names in your application). See Internationalization and localization.

Default: '/'

The path set on the language cookie. This should either match the URL path of your Django installation or be a parent of that path.

This is useful if you have multiple Django instances running under the same hostname. They can use different cookie paths and each instance will only see its own language cookie.

Be cautious when updating this setting on a production site. If you update this setting to use a deeper path than it previously used, existing user cookies that have the old path will not be updated. This will result in site users being unable to switch the language as long as these cookies persist. The only safe and reliable option to perform the switch is to change the language cookie name permanently (via the LANGUAGE_COOKIE_NAME setting), and to add a middleware that copies the value from the old cookie to a new one and then deletes the one.

Default: None

The value of the SameSite flag on the language cookie. This flag prevents the cookie from being sent in cross-site requests.

See SESSION_COOKIE_SAMESITE for details about SameSite.

Default: False

Whether to use a secure cookie for the language cookie. If this is set toTrue, the cookie will be marked as “secure”, which means browsers may ensure that the cookie is only sent under an HTTPS connection.

LANGUAGES

Default: A list of all available languages. This list is continually growing and including a copy here would inevitably become rapidly out of date. You can see the current list of translated languages by looking indjango/conf/global_settings.py.

The list is a list of 2-tuples in the format (language code, language name) – for example,('ja', 'Japanese'). This specifies which languages are available for language selection. SeeInternationalization and localization.

Generally, the default value should suffice. Only set this setting if you want to restrict language selection to a subset of the Django-provided languages.

If you define a custom LANGUAGES setting, you can mark the language names as translation strings using thegettext_lazy() function.

Here’s a sample settings file:

from django.utils.translation import gettext_lazy as _

LANGUAGES = [ ("de", _("German")), ("en", _("English")), ]

LANGUAGES_BIDI

Default: A list of all language codes that are written right-to-left. You can see the current list of these languages by looking indjango/conf/global_settings.py.

The list contains language codes for languages that are written right-to-left.

Generally, the default value should suffice. Only set this setting if you want to restrict language selection to a subset of the Django-provided languages. If you define a custom LANGUAGES setting, the list of bidirectional languages may contain language codes which are not enabled on a given site.

LOCALE_PATHS

Default: [] (Empty list)

A list of directories where Django looks for translation files. See How Django discovers translations.

Example:

LOCALE_PATHS = [ "/home/www/project/common_files/locale", "/var/local/translations/locale", ]

Django will look within each of these paths for the <locale_code>/LC_MESSAGESdirectories containing the actual translation files.

LOGGING

Default: A logging configuration dictionary.

A data structure containing configuration information. When not-empty, the contents of this data structure will be passed as the argument to the configuration method described in LOGGING_CONFIG.

Among other things, the default logging configuration passes HTTP 500 server errors to an email log handler when DEBUG is False. See alsoConfiguring logging.

You can see the default logging configuration by looking indjango/utils/log.py.

LOGGING_CONFIG

Default: 'logging.config.dictConfig'

A path to a callable that will be used to configure logging in the Django project. Points at an instance of Python’s dictConfig configuration method by default.

If you set LOGGING_CONFIG to None, the logging configuration process will be skipped.

MANAGERS

Default: [] (Empty list)

A list in the same format as ADMINS that specifies who should get broken link notifications whenBrokenLinkEmailsMiddleware is enabled.

MEDIA_ROOT

Default: '' (Empty string)

Absolute filesystem path to the directory that will hold user-uploaded files.

Example: "/var/www/example.com/media/"

See also MEDIA_URL.

Warning

MEDIA_ROOT and STATIC_ROOT must have different values. Before STATIC_ROOT was introduced, it was common to rely or fallback on MEDIA_ROOT to also serve static files; however, since this can have serious security implications, there is a validation check to prevent it.

MEDIA_URL

Default: '' (Empty string)

URL that handles the media served from MEDIA_ROOT, used for managing stored files. It must end in a slash if set to a non-empty value. You will need to configure these files to be served in both development and production environments.

If you want to use {{ MEDIA_URL }} in your templates, add'django.template.context_processors.media' in the 'context_processors'option of TEMPLATES.

Example: "https://media.example.com/"

Warning

There are security risks if you are accepting uploaded content from untrusted users! See the security guide’s topic onUser-uploaded content for mitigation details.

Warning

MEDIA_URL and STATIC_URL must have different values. See MEDIA_ROOT for more details.

Note

If MEDIA_URL is a relative path, then it will be prefixed by the server-provided value of SCRIPT_NAME (or / if not set). This makes it easier to serve a Django application in a subpath without adding an extra configuration to the settings.

MIDDLEWARE

Default: None

A list of middleware to use. See Middleware.

MIGRATION_MODULES

Default: {} (Empty dictionary)

A dictionary specifying the package where migration modules can be found on a per-app basis. The default value of this setting is an empty dictionary, but the default package name for migration modules is migrations.

Example:

{"blog": "blog.db_migrations"}

In this case, migrations pertaining to the blog app will be contained in the blog.db_migrations package.

If you provide the app_label argument, makemigrations will automatically create the package if it doesn’t already exist.

When you supply None as a value for an app, Django will consider the app as an app without migrations regardless of an existing migrations submodule. This can be used, for example, in a test settings file to skip migrations while testing (tables will still be created for the apps’ models). To disable migrations for all apps during tests, you can set theMIGRATE to False instead. IfMIGRATION_MODULES is used in your general project settings, remember to use the migrate --run-syncdb option if you want to create tables for the app.

MONTH_DAY_FORMAT

Default: 'F j'

The default formatting to use for date fields on Django admin change-list pages – and, possibly, by other parts of the system – in cases when only the month and day are displayed.

For example, when a Django admin change-list page is being filtered by a date drilldown, the header for a given day displays the day and month. Different locales have different formats. For example, U.S. English would say “January 1,” whereas Spanish might say “1 Enero.”

Note that the corresponding locale-dictated format has higher precedence and will be applied instead.

See allowed date format strings. See alsoDATE_FORMAT, DATETIME_FORMAT,TIME_FORMAT and YEAR_MONTH_FORMAT.

NUMBER_GROUPING

Default: 0

Number of digits grouped together on the integer part of a number.

Common use is to display a thousand separator. If this setting is 0, then no grouping will be applied to the number. If this setting is greater than0, then THOUSAND_SEPARATOR will be used as the separator between those groups.

Some locales use non-uniform digit grouping, e.g. 10,00,00,000 inen_IN. For this case, you can provide a sequence with the number of digit group sizes to be applied. The first number defines the size of the group preceding the decimal delimiter, and each number that follows defines the size of preceding groups. If the sequence is terminated with -1, no further grouping is performed. If the sequence terminates with a 0, the last group size is used for the remainder of the number.

Example tuple for en_IN:

NUMBER_GROUPING = (3, 2, 0)

Note that the locale-dictated format has higher precedence and will be applied instead.

See also DECIMAL_SEPARATOR, THOUSAND_SEPARATOR andUSE_THOUSAND_SEPARATOR.

PREPEND_WWW

Default: False

Whether to prepend the “www.” subdomain to URLs that don’t have it. This is only used if CommonMiddleware is installed (see Middleware). See also APPEND_SLASH.

ROOT_URLCONF

Default: Not defined

A string representing the full Python import path to your root URLconf, for example "mydjangoapps.urls". Can be overridden on a per-request basis by setting the attribute urlconf on the incoming HttpRequestobject. See How Django processes a request for details.

SECRET_KEY

Default: '' (Empty string)

A secret key for a particular Django installation. This is used to providecryptographic signing, and should be set to a unique, unpredictable value.

django-admin startproject automatically adds a randomly-generated SECRET_KEY to each new project.

Uses of the key shouldn’t assume that it’s text or bytes. Every use should go through force_str() orforce_bytes() to convert it to the desired type.

Django will refuse to start if SECRET_KEY is not set.

Warning

Keep this value secret.

Running Django with a known SECRET_KEY defeats many of Django’s security protections, and can lead to privilege escalation and remote code execution vulnerabilities.

The secret key is used for:

When a secret key is no longer set as SECRET_KEY or contained withinSECRET_KEY_FALLBACKS all of the above will be invalidated. When rotating your secret key, you should move the old key toSECRET_KEY_FALLBACKS temporarily. Secret keys are not used for passwords of users and key rotation will not affect them.

SECRET_KEY_FALLBACKS

Default: []

A list of fallback secret keys for a particular Django installation. These are used to allow rotation of the SECRET_KEY.

In order to rotate your secret keys, set a new SECRET_KEY and move the previous value to the beginning of SECRET_KEY_FALLBACKS. Then remove the old values from the end of the SECRET_KEY_FALLBACKS when you are ready to expire the sessions, password reset tokens, and so on, that make use of them.

Note

Signing operations are computationally expensive. Having multiple old key values in SECRET_KEY_FALLBACKS adds additional overhead to all checks that don’t match an earlier key.

As such, fallback values should be removed after an appropriate period, allowing for key rotation.

Uses of the secret key values shouldn’t assume that they are text or bytes. Every use should go through force_str() orforce_bytes() to convert it to the desired type.

SECURE_CONTENT_TYPE_NOSNIFF

Default: True

If True, the SecurityMiddlewaresets the X-Content-Type-Options: nosniff header on all responses that do not already have it.

SECURE_CROSS_ORIGIN_OPENER_POLICY

Default: 'same-origin'

Unless set to None, theSecurityMiddleware sets theCross-Origin Opener Policy header on all responses that do not already have it to the value provided.

SECURE_HSTS_INCLUDE_SUBDOMAINS

Default: False

If True, the SecurityMiddleware adds the includeSubDomains directive to the HTTP Strict Transport Securityheader. It has no effect unless SECURE_HSTS_SECONDS is set to a non-zero value.

SECURE_HSTS_PRELOAD

Default: False

If True, the SecurityMiddleware adds the preload directive to the HTTP Strict Transport Securityheader. It has no effect unless SECURE_HSTS_SECONDS is set to a non-zero value.

SECURE_HSTS_SECONDS

Default: 0

If set to a non-zero integer value, theSecurityMiddleware sets theHTTP Strict Transport Security header on all responses that do not already have it.

SECURE_PROXY_SSL_HEADER

Default: None

A tuple representing an HTTP header/value combination that signifies a request is secure. This controls the behavior of the request object’s is_secure()method.

By default, is_secure() determines if a request is secure by confirming that a requested URL uses https://. This method is important for Django’s CSRF protection, and it may be used by your own code or third-party apps.

If your Django app is behind a proxy, though, the proxy may be “swallowing” whether the original request uses HTTPS or not. If there is a non-HTTPS connection between the proxy and Django then is_secure() would always return False – even for requests that were made via HTTPS by the end user. In contrast, if there is an HTTPS connection between the proxy and Django thenis_secure() would always return True – even for requests that were made originally via HTTP.

In this situation, configure your proxy to set a custom HTTP header that tells Django whether the request came in via HTTPS, and setSECURE_PROXY_SSL_HEADER so that Django knows what header to look for.

Set a tuple with two elements – the name of the header to look for and the required value. For example:

SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https")

This tells Django to trust the X-Forwarded-Proto header that comes from our proxy and that the request is guaranteed to be secure (i.e., it originally came in via HTTPS) when:

You should only set this setting if you control your proxy or have some other guarantee that it sets/strips this header appropriately.

Note that the header needs to be in the format as used by request.META – all caps and likely starting with HTTP_. (Remember, Django automatically adds 'HTTP_' to the start of x-header names before making the header available in request.META.)

Warning

Modifying this setting can compromise your site’s security. Ensure you fully understand your setup before changing it.

Make sure ALL of the following are true before setting this (assuming the values from the example above):

If any of those are not true, you should keep this setting set to Noneand find another way of determining HTTPS, perhaps via custom middleware.

SECURE_REDIRECT_EXEMPT

Default: [] (Empty list)

If a URL path matches a regular expression in this list, the request will not be redirected to HTTPS. TheSecurityMiddleware strips leading slashes from URL paths, so patterns shouldn’t include them, e.g.SECURE_REDIRECT_EXEMPT = [r'^no-ssl/$', …]. IfSECURE_SSL_REDIRECT is False, this setting has no effect.

SECURE_REFERRER_POLICY

Default: 'same-origin'

If configured, the SecurityMiddleware sets the Referrer Policy header on all responses that do not already have it to the value provided.

SECURE_SSL_HOST

Default: None

If a string (e.g. secure.example.com), all SSL redirects will be directed to this host rather than the originally-requested host (e.g. www.example.com). If SECURE_SSL_REDIRECT is False, this setting has no effect.

SECURE_SSL_REDIRECT

Default: False

If True, the SecurityMiddleware redirects all non-HTTPS requests to HTTPS (except for those URLs matching a regular expression listed inSECURE_REDIRECT_EXEMPT).

Note

If turning this to True causes infinite redirects, it probably means your site is running behind a proxy and can’t tell which requests are secure and which are not. Your proxy likely sets a header to indicate secure requests; you can correct the problem by finding out what that header is and configuring the SECURE_PROXY_SSL_HEADER setting accordingly.

SERIALIZATION_MODULES

Default: Not defined

A dictionary of modules containing serializer definitions (provided as strings), keyed by a string identifier for that serialization type. For example, to define a YAML serializer, use:

SERIALIZATION_MODULES = {"yaml": "path.to.yaml_serializer"}

SERVER_EMAIL

Default: 'root@localhost'

The email address that error messages come from, such as those sent toADMINS and MANAGERS. This address is used in theFrom: header and can take any format valid in the chosen email sending protocol.

Why are my emails sent from a different address?

This address is used only for error messages. It is not the address that regular email messages sent with send_mail()come from; for that, see DEFAULT_FROM_EMAIL.

SHORT_DATE_FORMAT

Default: 'm/d/Y' (e.g. 12/31/2003)

An available formatting that can be used for displaying date fields on templates. Note that the corresponding locale-dictated format has higher precedence and will be applied instead. Seeallowed date format strings.

See also DATE_FORMAT and SHORT_DATETIME_FORMAT.

SHORT_DATETIME_FORMAT

Default: 'm/d/Y P' (e.g. 12/31/2003 4 p.m.)

An available formatting that can be used for displaying datetime fields on templates. Note that the corresponding locale-dictated format has higher precedence and will be applied instead. Seeallowed date format strings.

See also DATE_FORMAT and SHORT_DATE_FORMAT.

SIGNING_BACKEND

Default: 'django.core.signing.TimestampSigner'

The backend used for signing cookies and other data.

See also the Cryptographic signing documentation.

SILENCED_SYSTEM_CHECKS

Default: [] (Empty list)

A list of identifiers of messages generated by the system check framework (i.e. ["models.W001"]) that you wish to permanently acknowledge and ignore. Silenced checks will not be output to the console.

See also the System check framework documentation.

STORAGES

Default:

{ "default": { "BACKEND": "django.core.files.storage.FileSystemStorage", }, "staticfiles": { "BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage", }, }

A dictionary containing the settings for all storages to be used with Django. It is a nested dictionary whose contents map a storage alias to a dictionary containing the options for an individual storage.

Storages can have any alias you choose. However, there are two aliases with special significance:

The following is an example settings.py snippet defining a custom file storage called example:

STORAGES = { # ... "example": { "BACKEND": "django.core.files.storage.FileSystemStorage", "OPTIONS": { "location": "/example", "base_url": "/example/", }, }, }

OPTIONS are passed to the BACKEND on initialization in **kwargs.

A ready-to-use instance of the storage backends can be retrieved fromdjango.core.files.storage.storages. Use a key corresponding to the backend definition in STORAGES.

Is my value merged with the default value?

Defining this setting overrides the default value and is not merged with it.

TEMPLATES

Default: [] (Empty list)

A list containing the settings for all template engines to be used with Django. Each item of the list is a dictionary containing the options for an individual engine.

Here’s a setup that tells the Django template engine to load templates from thetemplates subdirectory inside each installed application:

TEMPLATES = [ { "BACKEND": "django.template.backends.django.DjangoTemplates", "APP_DIRS": True, }, ]

The following options are available for all backends.

BACKEND

Default: Not defined

The template backend to use. The built-in template backends are:

You can use a template backend that doesn’t ship with Django by settingBACKEND to a fully-qualified path (i.e. 'mypackage.whatever.Backend').

NAME

Default: see below

The alias for this particular template engine. It’s an identifier that allows selecting an engine for rendering. Aliases must be unique across all configured template engines.

It defaults to the name of the module defining the engine class, i.e. the next to last piece of BACKEND, when it isn’t provided. For example if the backend is 'mypackage.whatever.Backend' then its default name is 'whatever'.

DIRS

Default: [] (Empty list)

Directories where the engine should look for template source files, in search order.

APP_DIRS

Default: False

Whether the engine should look for template source files inside installed applications.

OPTIONS

Default: {} (Empty dict)

Extra parameters to pass to the template backend. Available parameters vary depending on the template backend. SeeDjangoTemplates andJinja2 for the options of the built-in backends.

TEST_RUNNER

Default: 'django.test.runner.DiscoverRunner'

The name of the class to use for starting the test suite. SeeUsing different testing frameworks.

TEST_NON_SERIALIZED_APPS

Default: [] (Empty list)

In order to restore the database state between tests forTransactionTestCases and database backends without transactions, Django will serialize the contents of all appswhen it starts the test run so it can then reload from that copy before running tests that need it.

This slows down the startup time of the test runner; if you have apps that you know don’t need this feature, you can add their full names in here (e.g.'django.contrib.contenttypes') to exclude them from this serialization process.

THOUSAND_SEPARATOR

Default: ',' (Comma)

Default thousand separator used when formatting numbers. This setting is used only when USE_THOUSAND_SEPARATOR is True andNUMBER_GROUPING is greater than 0.

Note that the locale-dictated format has higher precedence and will be applied instead.

See also NUMBER_GROUPING, DECIMAL_SEPARATOR andUSE_THOUSAND_SEPARATOR.

TIME_FORMAT

Default: 'P' (e.g. 4 p.m.)

The default formatting to use for displaying time fields in any part of the system. Note that the locale-dictated format has higher precedence and will be applied instead. See allowed date format strings.

See also DATE_FORMAT and DATETIME_FORMAT.

TIME_INPUT_FORMATS

Default:

[ "%H:%M:%S", # '14:30:59' "%H:%M:%S.%f", # '14:30:59.000200' "%H:%M", # '14:30' ]

A list of formats that will be accepted when inputting data on a time field. Formats will be tried in order, using the first valid one. Note that these format strings use Python’s datetime module syntax, not the format strings from the datetemplate filter.

The locale-dictated format has higher precedence and will be applied instead.

See also DATE_INPUT_FORMATS and DATETIME_INPUT_FORMATS.

TIME_ZONE

Default: 'America/Chicago'

A string representing the time zone for this installation. See the list of time zones.

Note

Since Django was first released with the TIME_ZONE set to'America/Chicago', the global setting (used if nothing is defined in your project’s settings.py) remains 'America/Chicago' for backwards compatibility. New project templates default to 'UTC'.

Note that this isn’t necessarily the time zone of the server. For example, one server may serve multiple Django-powered sites, each with a separate time zone setting.

When USE_TZ is False, this is the time zone in which Django will store all datetimes. When USE_TZ is True, this is the default time zone that Django will use to display datetimes in templates and to interpret datetimes entered in forms.

On Unix environments (where time.tzset() is implemented), Django sets theos.environ['TZ'] variable to the time zone you specify in theTIME_ZONE setting. Thus, all your views and models will automatically operate in this time zone. However, Django won’t set the TZenvironment variable if you’re using the manual configuration option as described in manually configuring settings. If Django doesn’t set the TZenvironment variable, it’s up to you to ensure your processes are running in the correct environment.

Note

Django cannot reliably use alternate time zones in a Windows environment. If you’re running Django on Windows, TIME_ZONE must be set to match the system time zone.

USE_I18N

Default: True

A boolean that specifies whether Django’s translation system should be enabled. This provides a way to turn it off, for performance. If this is set toFalse, Django will make some optimizations so as not to load the translation machinery.

See also LANGUAGE_CODE and USE_TZ.

USE_THOUSAND_SEPARATOR

Default: False

A boolean that specifies whether to display numbers using a thousand separator. When set to True, Django will format numbers using theNUMBER_GROUPING and THOUSAND_SEPARATOR settings. The latter two settings may also be dictated by the locale, which takes precedence.

See also DECIMAL_SEPARATOR, NUMBER_GROUPING andTHOUSAND_SEPARATOR.

USE_TZ

Default: True

A boolean that specifies if datetimes will be timezone-aware by default or not. If this is set to True, Django will use timezone-aware datetimes internally.

When USE_TZ is False, Django will use naive datetimes in local time, except when parsing ISO 8601 formatted strings, where timezone information will always be retained if present.

See also TIME_ZONE and USE_I18N.

USE_X_FORWARDED_HOST

Default: False

A boolean that specifies whether to use the X-Forwarded-Host header in preference to the Host header. This should only be enabled if a proxy which sets this header is in use.

This setting takes priority over USE_X_FORWARDED_PORT. PerRFC 7239 Section 5.3, the X-Forwarded-Host header can include the port number, in which case you shouldn’t use USE_X_FORWARDED_PORT.

USE_X_FORWARDED_PORT

Default: False

A boolean that specifies whether to use the X-Forwarded-Port header in preference to the SERVER_PORT META variable. This should only be enabled if a proxy which sets this header is in use.

USE_X_FORWARDED_HOST takes priority over this setting.

WSGI_APPLICATION

Default: None

The full Python path of the WSGI application object that Django’s built-in servers (e.g. runserver) will use. The django-admin startproject management command will create a standardwsgi.py file with an application callable in it, and point this setting to that application.

If not set, the return value of django.core.wsgi.get_wsgi_application()will be used. In this case, the behavior of runserver will be identical to previous Django versions.

YEAR_MONTH_FORMAT

Default: 'F Y'

The default formatting to use for date fields on Django admin change-list pages – and, possibly, by other parts of the system – in cases when only the year and month are displayed.

For example, when a Django admin change-list page is being filtered by a date drilldown, the header for a given month displays the month and the year. Different locales have different formats. For example, U.S. English would say “January 2006,” whereas another locale might say “2006/January.”

Note that the corresponding locale-dictated format has higher precedence and will be applied instead.

See allowed date format strings. See alsoDATE_FORMAT, DATETIME_FORMAT, TIME_FORMATand MONTH_DAY_FORMAT.

X_FRAME_OPTIONS

Default: 'DENY'

The default value for the X-Frame-Options header used byXFrameOptionsMiddleware. See theclickjacking protection documentation.