Managing Django’s settings

Nikita Sobolev
Apr 1, 2017 · 3 min read
Image for post
Image for post
Organize Django settings into multiple files and directories. Easily override and modify settings. Use wildcards and optional settings files.

Managing Django’s settings might be tricky. There are severals issues which are encountered by any Django developer along the way.

First one is caused by the default project structure. Django clearly offers us a single file. It seams reasonable at the first glance. And it is actually easy to use just after the start. But when it comes to the real-world it only causes misunderstanding and frustration .

At some point, you will need to put some kind of personal settings in the main file: certificate paths, your username or password, database connection, etc. But putting your user-specific values inside the common settings is a bad practice. Other developers would have other settings, and it would just not work for all of you. The most known hack for this situation is . This file is placed near the regular settings file and ignored from version control. There are also these lines which are usually put somewhere in the end of :

Looks pretty straight-forward. It is also sometimes accompanied with , which is version controlled, to keep your local settings structure up to date.

You would definitely need production settings sometime soon. How would you do that? Create a new file. Do you need special settings for testing? Create a new file. Staging? New file. You would have a lot of files.

Secondly, when you have a lot of things to configure, your settings files will become long and heavy. At this point you would start to think: maybe I could separate these values into different files and reuse them at different environments? If this thought has ever come to your mind — you should give a try.


How does solve these issues? This helper provides a user-friendly interface to store your settings in different files. Let’s look at the example. Imagine you have an existing project with , , , , and emails.

Before we start, let’s install with:

pip install django-split-settings

That’s what your files would look like after adopting :

That’s a clear separation of the settings based on two factors: what component they are configuring and at what environment we are working right now. And the flexibility of the library allows you to have any structure you want, not just the one described here.

In our we can define any logic we want. Basically, we would just define what kind of components we would like to use and select the environment. Here’s an example, we use in production for all our projects:

Code example

And that’s it. Our application would run as usual. We have achieved multiple goals with so few lines of code:

  1. We now have separated settings based on what they configure. Gaining readability and maintainability
  2. We now have separated settings based on environment
  3. We now have optional local settings with now dirty hacks
  4. We did not have to do any refactoring except just some basic restructuring

We have also created a project example, which can be used as a template for your own projects:

What’s not covered

In a future articles we would cover two topics which are crucial when dealing with project’s configuration:

  1. Secret settings
  2. Dynamic settings


Got any ideas or feedback? Dive in, if you want to contribute:

We love Python and Elixir. We use Javascript.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

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