12factor config support for Django
What is it?
Django is an awesome Python web framework.
“The Twelve-Factor App” is an awesome methodology for building SaaS apps.
Still not sure of the benefits? Check out “Twelve-Factor Config: Misunderstandings and Advice”.
pip install dj12
At the end of your settings.py, add:
from dj12.config import *
And it’s done, your app supports 12factor config!
Still, you may want to delete obsolete config variables:
We also provide modern defaults for these variables, so you don’t need to set them yourself:
- USE_I18N = True
- USE_L10N = True
- USE_TZ = True
Default settings are optimized for the development environments, and for doing nothing if you don’t use that particular Django feature. Change them only when you need to do so - for example, set DATABASE_URL when you need database persistency on production, and CACHE_URL when you need out-of-process cache on production.
SECRET_KEY (required when DEBUG=off)
A secret key for a particular environment. This is used to provide cryptographic signing, and should be set to a unique, unpredictable value.
This is the only required setting, because it’s a security issue to run without SECRET_KEY on production.
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.
Read more at Django: SECRET_KEY.
URL prefix for all URLs exposed by this service.
If this is a https:// URL:
- all non-https accesses will get redirected to https:// URLs (SECURE_SSL_REDIRECT),
- cookies will be set as https-only (SESSION_COOKIE_SECURE),
- HTTP Strict Transport Security will be enabled.
Access from different hostnames than the one set in BASE_URL will be blocked (ALLOWED_HOSTS) - note that you may override this behavior by setting ALLOWED_HOSTS environment variable.
|Type:||comma separated list|
|Default value:||host of the BASE_URL|
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.
We recommend to use only a single base URL - and set it with BASE_URL - to access your service, no matter if it’s accessed by end users or other services, from internal or external networks, etc. That’s because it’s simpler, and it’s commonly necessary for a service to know its URL, and to be able to send it to another service - even in a non-web context (e.g. in background workers or batch jobs).
Read more at Django: ALLOWED_HOSTS.
Turn this on if your app is behind a reverse proxy that sends X-Forwarded-Proto header. This header tells Django if the request was sent thru a secure connection.
You will probably open security holes in your site if you set this without knowing what you’re doing. And if you fail to set it when you should. Seriously.
Read more at Django: SECURE_PROXY_SSL_HEADER.
Turn this on if you are ready to add your website to the list of HTTPS-only websites distributed with all major browsers. This will mean that browsers will refuse to access it thru insecure connections, making a lot of man-in-the-middle attacks impossible.
Read more at hstspreload.org.
Turn this on to inform browsers that HTTPS shall be required for all subdomains of your domain.
|Default value:||10886400 (18 weeks) if HSTS_PRELOAD is on, else 3600 (1 hour) if BASE_URL uses https:// scheme, else 0|
For how long browsers should refuse to access your domain thru insecure connections.
A boolean that turns on/off debug mode.
Never deploy a site into production with DEBUG turned on.
Did you catch that? NEVER deploy a site into production with DEBUG turned on.
Read more at Django: DEBUG.
|Default value:||sqlite:///db.sqlite3 (db.sqlite3 file in the current working directory)|
This is the URL to your database.
Note: This configures the Django’s “default” database; you may also use WHATEVER_*DATABASE_URL to configure “*whatever” database.
Read more at dj-database-url.
|Default value:||locmem:// (memory)|
This is the URL to your caching system.
Note: This configures the Django’s “default” cache; you may also use WHATEVER_*CACHE_URL to configure “*whatever” cache.
Read more at django-cache-url.
|Default value:||console:// (print emails to the console)|
This is the URL to your email sending system.
- SMTP Submission backend (submit:// - submit URI scheme)
- console backend (console://)
- file backend (file://)
- in-memory backend (memory://)
- dummy backend (dummy://)
With SMTP Submission backend, port 587 is used by default, and TLS is enabled. To disable TLS, add ?tls=off. To use legacy SMTP-over-SSL (usually on port 465), add ?ssl=on.
Sentry DSN - use this if you’re using Sentry to monitor your app.
Note that you still have to add Raven app to INSTALLED_APPS, as we don’t want to always require it, and modifying the list of installed apps based on the environment variables is a bad idea. However, you may safely run Django with Raven installed but RAVEN_URL unset.
Default email address to use for emails sent to users.
Read more at Django: DEFAULT_FROM_EMAIL.
Default language for the environment. Supports both standard language ID format, and UNIX $LANG format.
It serves two purposes:
- If the locale middleware isn’t in use, it decides which translation is served to all users.
- If the locale middleware is active, it provides a fallback language in case the user’s preferred language can’t be determined or is not supported by the website. It also provides the fallback translation when a translation for a given literal doesn’t exist for the user’s preferred language.
Read more at Django: LANGUAGE_CODE.
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.