Configuring Django Settings: Best Practices

This article is intended for engineers who use the Django framework. It gives a deep insight and best practices into configuring Django project settings, and the pros and cons of different approaches.

In the article, Django settings.py explained, you will also find recommendations concerning tools, best practices, and architectural solutions, all time-tested and proven by successful projects. And if you still have questions after reading it, you can always leave a comment below or use our contact form. The article is based on Django Stars’ vast experience with real projects. Our Django Developers team is ready to speed up your development project.

Managing Django Settings: Issues

Different environments. Usually, you have several environments: local, dev, ci, qa, staging, production, etc. Each environment can have its own specific settings (for example: DEBUG = True, more verbose logging, additional apps, some mocked data, etc). You need an approach that allows you to keep all these Django setting configurations.

Sensitive data. You have SECRET_KEY in each Django project. On top of this there can be DB passwords and tokens for third-party APIs like Amazon or Twitter. This data cannot be stored in VCS.

Sharing settings between team members. You need a general approach to eliminate human error when working with the settings. For example, a developer may add a third-party app or some API integration and fail to add specific settings. On large (or even mid-size) projects, this can cause real issues.

Django settings are a Python code. This is a curse and a blessing at the same time. It gives you a lot of flexibility, but can also be a problem – instead of key-value pairs, settings.py can have a very tricky logic.

Django Secret Key: How to Protect

SECRET_KEY is used for cryptographic signing in Django, so it must be kept safe.

Django uses salt stored in the SECRET_KEY variable to create hashes of sensitive data. This means anyone who has access to the project’s SECRET_KEY, also has access to all sensitive information.

SECRET_KEY may be found in the settings.py file. It’s usually a variable containing a random string.

Note: don’t share SECRET_KEY in your project repositories.

To create a new SECRET_KEY, use the next command:

django.core.management.utils.get_random_secret_key

Then, you need to open a Python shell in the required directory and use the command below:

python3 manage.py shell

from django.core.management.utils import get_random_secret_key
print(get_random_secret_key())

The last thing you must do is copy the generated SECRET_KEY and paste it into the settings.py file.

Setting Django Configurations: Different Approaches

There is no built-in universal way to configure Django settings without hardcoding them. But books, open-source and work projects provide a lot of recommendations and approaches on how to do it best. Let’s take a brief look at the most popular ones to examine their weaknesses and strengths.

settings_local.py

When configuring a new Django project, it’s common to create a local settings template module, which is excluded from version control. The developer can determine which settings are local, but it may not be so convenient because they need to set additional values and ensure they are valid.

If a Django project has only one settings module, the local settings file can define base settings and specify what settings should be local or secret. Here’s an example:

settings.py file:

settings_local.py file:

Local settings can be situated inside other settings. You can add there doc strings, which are displayed when prompting, and default values required for when prompting.

When the local settings file is created and set up, you may add the following line: inject_settings(). This command specify which settings can be considered local and merges them from the settings file.

After inject_settings() runs, it’s possible to access the local settings in the settings module For example, if you run if DEBUG, then DEBUG is no longer in the local settings.

When you run a manage.py command, all missing local settings will be prompted to enter. If there are no required files, they will be created.

Pros:

• Secrets not in VCS.

Cons:

• settings_local.py is not in VCS, so you can lose some of your Django environment settings.
• The Django settings file is a Python code, so settings_local.py can have some non-obvious logic.
• You need to have settings_local.example (in VCS) to share the default Django configurations for developers.

Separate settings file for each environment

This is an extension of the previous approach. It allows you to keep all configurations in VCS and to share default settings between developers.

Running different environments requires separate settings files. By default, a Django project contains a single settings.py file. But creating more of them is possible, giving each a different name. Also, you can make a package to keep all settings files together. Just like that:

settings/
   ├── __init__.py
   ├── base.py
   ├── ci.py
   ├── local.py
   ├── staging.py
   ├── production.py
   └── qa.py

Once you have created multiple settings files, the project’s manage.py file requires updates — you must specify the relevant settings file, not the default one.

When multiple settings files are created and set up, you can use them in a Django project. Import a chosen settings file in your code by using the following code:


The code imports all variables from settings_base.py into the module you’re using.

Also, you can specify which settings file you need to use when the Django application starts. For example, if you need to use local settings, run the application using the following command:

So, the system will start an app with a settings_local.py file, not a default one.

Next, consider the option when you have to override some specific settings in a settings file. It may be helpful to use different databases for production and development environments.

To do it, you need to redefine settings in the required settings file. For example, the project uses SQLite for the development environment and PostgreSQL for production. In such a case, you must define a different database for each environment in each respective settings file.

# settings_dev.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
    }
}

# settings_prod.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'database',
        'USER': 'user',
        'PASSWORD': 'password',
        'HOST': 'host',
        'PORT': '',
    }
}

Pros:

• All environments are in VCS.
• It’s easy to share settings between developers.

Cons:

• You need to find a way to handle secret passwords and tokens.
• “Inheritance” of settings can be hard to trace and maintain.

Environment variables

Django variables may be used to secure sensitive data, such as passwords, secret keys, API IDs, etc.

There are two things you must remember:

The list of variables may be as long as your project needs. After listing variables in the .env file, you can replace explicit values in the settings.py file with those from the Django environment variables file.

This is the simplest example using Python os.environ and it has several issues:

1. You need to handle KeyError exceptions.
2. You need to convert types manually (see DATABASE_PORT usage).

To fix KeyError, you can write your own custom wrapper. For example:

Run the project’s development server to check whether all the variables are set correctly.

Also, you can set default values for this wrapper and add type conversion. But actually there is no need to write this wrapper, because you can use a third-party library (we’ll talk about this later).

The .env file contains sensitive data, so you shouldn’t upload it to a git repository. Instead, you must add the file to the list of .gitignore files for your Django project. There, you should keep all the files and directories you don’t want to upload to git.

Pros:

• Django config is separated from code.
• Environment parity – you have the same code for all environments.
• No inheritance in settings, and cleaner and more consistent code.
• There is a theoretical grounding for using Django environment variables – 12 Factors.

Cons:

• You need to handle sharing default config between developers.

12 Factors

12 Factors is a collection of recommendations on how to build distributed web-apps that will be easy to deploy and scale in the Cloud. It was created by Heroku, a well-known Cloud hosting provider.
As the name suggests, the collection consists of twelve parts:

1. Codebase
2. Dependencies
3. Config
4. Backing services
5. Build, release, run
6. Processes
7. Port binding
8. Concurrency
9. Disposability
10. Dev/prod parity
11. Logs
12. Admin processes

Each point describes a recommended way to implement a specific aspect of the project. Some of these points are covered by instruments like Django, Python, pip. Some are covered by design patterns or the infrastructure setup. In the context of this article, we are interested in one part: Configuration.

Its main rule is to store configuration in the environment. Following this recommendation will give us strict separation of config from code.
You can read more on 12factor.net.

django-environ

Based on the above, we see that Django env variables are the perfect place to store settings.
Now it’s time to talk about the toolkit.

Writing code using os.environ could be tricky sometimes and require additional effort to handle errors. It’s better to use django-environ instead.

Technically it’s a merge of:

• envparse
• honcho
• dj-database-url
• dj-search-url
• dj-config-url
• django-cache-url

This app gives a well-functioning API for reading values from environment variables or text files, handful type conversion, etc. Let’s look at some examples.
Django settings.py file before:

Settings.py in Django after:

.env file:

Setting Structure

Instead of splitting settings by environments, you can split them by the source: Django, third- party apps (Celery, DRF, etc.), and your custom settings.

File structure:

project/
├── apps/
├── settings/
│   ├── __init__.py
│   ├── djano.py
│   ├── project.py
│   └── third_party.py
└── manage.py

__init__.py file:

Each module could be done as a package, and you can split it more granularly:

project/
├── apps/
├── settings/
│   ├── project
│   │   ├── __init__.py
│   │   ├── custom_module_foo.py
│   │   ├── custom_module_bar.py
│   │   └── custom_module_xyz.py
│   ├── third_party
│   │   ├── __init__.py
│   │   ├── celery.py
│   │   ├── email.py
│   │   └── rest_framework.py
│   ├── __init__.py
│   └── djano.py
└── manage.py

Naming Conventions

Naming of variables is one of the most complex parts of development. So is naming of settings. We can’t imply on Django or third-party applications, but we can follow these simple rules for our custom (project) settings:

• Give meaningful names to your settings.
• Always use the prefix with the project name for your custom (project) settings.
• Write descriptions for your settings in comments.

Bad example:

Good example:

Change MYAWESOMEPROJECT to you real project name.

Django Settings: Best practices

Here are some of the Django production settings best practices:

• Use a web server ready for production. The best options for a Django application are Apache or Nginx. These servers can withstand high traffic and have better security systems than default Django servers.
• Apply PostgreSQL or MySQL databases. These databases handle high traffic better than the default SQLite.
• Adopt Memcached or Redis cashing systems. With their help, developers can speed up the response time for an app.
• Add HAProxy or NGINX load balancers to share the load between servers. It will make an application more stable.
• Use Logstash, Elasticsearch, or Kibana logging systems. They allow the configuration of an app for different environments and ensure the correct settings for each of them.
• Adopt Prometheus, Grafana, or Nagios monitoring systems. These systems will help you detect and solve severe issues in time.
• Apply Docker. A proper containerization technology helps package an application and its dependencies, allowing it to deploy and upscale an app quickly.

Read also: Python Rule Engine: Logic Automation & Examples

Conclusion

The Settings file is a small but very important part of any Django project. If you do it wrong, you’ll have a lot of issues during all phases of development. But if you do it right, it will be a good basis for your project that will allow it to grow and scale in the future.

Using the Django settings environment variables approach, you can easily switch from a monolith to microservice architecture, wrap your project in Docker containers, and deploy it in any VPS or Cloud hosting platform such as: Amazon, Google Cloud, or your own Kubernetes cluster.

Properly utilizing Django models methods can significantly enhance your application’s database interactions and data management.

If you are looking for experienced developers for your project, contact the Django Stars team.

Sources:

• https://12factor.net/
• https://django-environ.readthedocs.io/en/latest/