Splitting Django Settings for Local and Production Development

I have been working on a few projects that use Django 2+ and deploying them to Azure Docker container. I do have one problem though; my development settings are very much different from my production. So, I have divided settings.py into a package with — base.py, local.py and production.py:

__init__.py file

Here, we check for local.py, if it exists this is imported and if not, production.py is used.

base.py file

This is the base for both local and production, the common code. Now it depends if you want to use the same SECRET_KEY on both production and local, I use it in both ways. If it’s a commercial project, I separate it and if not I put it in the base.py. Also, if you are using external logging providers such as Logstash or Sentry, you might want to separate LOGGING too.

local.py file

I always separate my database, and I also make sure that they are the same type of database, in my case it’s PostgreSQL. Also, it contains the location for the static file and where the user can upload their files.

Code:

production.py file

This is where I use external services such as Azure, AWS or Heroku to add their production settings. I also restrict the access to one domain, disable DEBUG, use whitenoise for static assets and use dj_database_url for parsing PostgreSQL URL.

The code:

Finally

One last tip is that I use my secrets as an environment variable or use the Azure Key Vault; this gives extra security and flexibility.

Happy coding.

PhD student, currently doing research on Spiking Neural Networks and Brain Computer Interfaces

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store