Configuring Django Settings for Production


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 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.

Let’s get started

To get the full working version of this guide, clone the conduit-django repository and follow the instructions in the file called to get everything installed and running. I've created a Production-Settings branch of the conduit project with the changes below.

Currently, our application has the following directory structure:

Change the existing to our common settings

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

This 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 and with the following:

from conduit.settings.common import *

The two files we created will import variables from the file. They'll also contain settings specific to each environment. If you have additional environments that you want to set specific 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:

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['SECRET_KEY']

# SECURITY WARNING: update this when you have the production host
ALLOWED_HOSTS = ['', 'localhost']

We also want to specify what ALLOWED_HOSTS are going to be set. Once you set DEBUG = FALSE THEN ALLOWED_HOSTS then needs to have a value for your project to run. Replace the values I've temporarily placed in here with your production host values.

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

Update the default value of DJANGO_SETTINGS_MODULE

In and with conduit.settings.development, change

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


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

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

There are other areas that you may need to account for when deploying to production. The Django Documentation has a checklist of things you should also consider.

Production Database

With reguards to our database, we have been using the built-in db.sqlite3. Sqlite isn't considered a production solution database. You will want to upgrade to PostgreSQL or MySQL for your production version. The documentation below talk about deploying to production and setting up the production worthy database.


I finished! On to the next tutorial