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.
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 README.md 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:
|-conduit/ |_|-settings.py |-manage.py |-requirements.txt |-.gitignore
settings.pyto 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 file will contain the settings that will be used in both development and production.
settings folder, create two files named
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 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:
|-conduit/ |_|-settings/ |__|-common.py |__|-development.py |__|-production.py |-manage.py |-requirements.txt |-.gitignore
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
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 = ['0.0.0.0', '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
settings.py which no longer exists, so trying to run our server or any
manage.py tasks will fail.
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
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.
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.