Django

Configuring Django Settings for Production

Up to date (Dec '18) Django

While Django makes it very simple to get an application running locally, the default configuration that's generated left untouched is unsuitible for production use. This lesson will show you how to separate your settings between development and production environments. Our Django application will be named conduit in this example, so sure to replace any references to conduit with the name of your Django application if it differs.

By default, our application's settings.py contains settings that should only be used for development, such as having DEBUG set to true, and having a hard-coded string for SECRET_KEY. One possible solution is exporting these settings to environment variables to separate our development and production environments, but environment variables can be a hassle to set up in development, especially when working with a team, so it makes sense to have some variables hard-coded in development. We'll be separating our configuration in to three files: a common file for storing the settings that remain the same in both development and production, and one for each of our production and development environments that will import the common settings.

Currently, our application has the following directory structure:

|-conduit/
|_|-settings.py
|-manage.py
|-requirements.txt
|-.gitignore
Change the existing settings.py to our common settings

Create a folder named settings in the same folder as our settings.py file. Then, move settings.py into the settings folder, and rename the file to common.py

This common.py file will contain the settings that will be used in both development and production.

Create additional setting files for our environments

In the settings folder, create two files named development.py and production.py with the following:

from conduit.settings.common import *

The two files we created will import variables from the common.py file. They'll also contain settings specific to each environment. If you have additional environments that you want to set specifict settings for (like for running tests), you can put them in the settings folder and import the common settings as well.

The resulting directory structure should look like this:

|-conduit/
|_|-settings/
|__|-common.py
|__|-development.py
|__|-production.py
|-manage.py
|-requirements.txt
|-.gitignore
Splitting up specific settings

Now that we have separate setting files for each environment, we can move environment specific settings to their respective folders. The settings to move will largely depend on what settings your app is using, but at a minimum you should move the hard-coded DEBUG and SECRET_KEY from the common settings to development settings, then in your production settings you can hard-code DEBUG to false and SECRET_KEY to read from an environment variable:

DEBUG = False

SECRET_KEY = os.environ.get('SECRET_KEY')

By default, Django will continue to look for configuration in settings.py which no longer exists, so trying to run our server or any manage.py tasks will fail.

Update the default value of DJANGO_SETTINGS_MODULE

In wsgi.py and manage.py with conduit.settings.development, change

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "conduit.settings")

to

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "conduit.settings.development")

This makes our Django application use the development.py file when the DJANGO_SETTINGS_MODULE environment variable is not set. In production, we can change our application to read the settings from production.py by simply setting the DJANGO_SETTINGS_MODULE environment variable to conduit.settings.production

 

I finished! On to the next tutorial