Automating the right configurations for local and production settings for the Django web application can save time before any deployment. By using different configurations, files save time for developers as well to set up a local environment in the local machine. We can restrict the access of production credentials to the limited developer or only Devops member by keeping credentials in environment variables.
What is the settings file in Django?
The settings.py file has all configurations of the Django web application. For example, how many applications are installed, what time zone server will consider, database connectivity configurations, static files configurations, whether debug mode is on or off?
Here is the official explanation of settings module from Django documentation.
If we have one single settings.py, we have to update the debug mode, database settings, and global variables used in production differently. So it is best practice to have multiple settings file for multiple environments.
It is best practice to store secrets in environment variables and use them in settings.py. I have written a blog on how to manage secrets and sensitive information for Django web application development.
Steps to define local and production settings file in Django web application development
- Create separate settings files for the local and production environment.
- Load the environment variables in settings files.
- Run the server
To know what is environment variables and how to use the environment variables to maintain secrets, please check How to use env variables to hide passwords/secrets from env files?
Please check the GitHub repository for the project source code.
Create separate settings files for the local and production environment.
- When you create a Django application, it will create settings.py file with default settings configuration. But always, the settings configurations are different for local machines and production servers. We must manage different settings files for a different environment.
- Create settings package and create multiple settings files as below:
. ├── manage.py ├── requirements.txt ├── django_settings_configurtaion │ ├── settings │ │ ├── __init__.py │ │ ├── default.py │ │ ├── local.py │ │ ├── staging.py │ │ ├── production.py │ ├── urls.py │ ├── wsgi.py
- The purpose of the default.py is to contain all common configurations ( like “INSTALLED_APPS,” “MIDDLEWARE,” and other configurations ) in it.
- The purpose of local.py or stagging.py or production.pyis to contain all environment-specific configurations like “like “DATABASES” and other configurations.
- So now, default.py file contains the common configuration for all the environments, and other files ( local.py, staging.py, and production.py ) contain the different environment-specific configurations.
Load the settings configurations on the basis of the environment.
- Install python-dotenv library by pip install python-dotenv package.
- This library loads .env file variables to operating system environment variables.
- create “.env” file inside the settings file and update the files as follow:
- Edit __init__.py file as below:
import os from dotenv import load_dotenv load_dotenv() ENVIRONMENT = os.getenv("ENVIRONMENT", os.getenv("APP_ENVIRONMENT")) if ENVIRONMENT == "staging": from .staging import * elif ENVIRONMENT == "production": from .production import * else: from .local import *
- So now, when the settings module will be interpreted by Django dynamically, the value of the environment variable “APP_ENVIRONMENT” defines to load which settings module in the Django application server.
Run the server
- Now, as we have mentioned APP_ENVIRONMENT= “local” the local settings configurations will be loaded.
- To run the server use the command python manage.py runserver
- We are now loading different settings modules dynamically.
- By adjusting the environment variable, the Appropriate settings module gets loaded on the Django web application server.
- So you can get rid of commenting out local development settings from settings file in Django web application before deploying to google cloud, aws, azure, or any virtual machine.
- I am sure this practice will save you time and avoid mistakes of deploying in production with local configurations that are avoided.