How do you configure Django for simple development and deployment?

How do you configure Django for simple development and deployment?

I tend to use SQLite when doing Django
development, but on a live server something more robust is
often needed (MySQL/PostgreSQL, for example).
Invariably, there are other changes to make to the Django
settings as well: different logging locations / intensities,
media paths, etc.
How do you manage all these changes to make deployment a
simple, automated process?


Answer 1:

Update: django-configurations has been released which is probably a better option for most people than doing it manually.

If you would prefer to do things manually, my earlier answer still applies:

I have multiple settings files.

  • – host-specific configuration, such as database name, file paths, etc.
  • – configuration used for development, e.g. DEBUG = True.
  • – configuration used for production, e.g. SERVER_EMAIL.

I tie these all together with a file that firstly imports, and then one of the other two. It decides which to load by two settings inside settings_local.pyDEVELOPMENT_HOSTS and PRODUCTION_HOSTS. calls platform.node() to find the hostname of the machine it is running on, and then looks for that hostname in the lists, and loads the second settings file depending on which list it finds the hostname in.

That way, the only thing you really need to worry about is keeping the file up to date with the host-specific configuration, and everything else is handled automatically.

Check out an example here.

Answer 2:

Personally, I use a single for the project, I just have it look up the hostname it’s on (my development machines have hostnames that start with “gabriel” so I just have this:

import socket
if socket.gethostname().startswith('gabriel'):
    LIVEHOST = False
    LIVEHOST = True

then in other parts I have things like:

    DEBUG = False
    PREPEND_WWW = True
    MEDIA_URL = ''
    DEBUG = True
    PREPEND_WWW = False
    MEDIA_URL = 'http://localhost:8000/static/'

and so on. A little bit less readable, but it works fine and saves having to juggle multiple settings files.

Answer 3:

At the end of I have the following:

    from settings_local import *
except ImportError:

This way if I want to override default settings I need to just put right next to

Answer 4:

I have two files. which contains common/default settings, and which is checked into source control. Each deployment has a separate, which executes from settings_base import * at the beginning and then overrides as needed.

Answer 5:

The most simplistic way I found was:

1) use the default for local development and 2)
create a starting with:

import os
from settings import *

And then just override the settings that differ in production:

DEBUG = False

    'default': {

Answer 6:

Somewhat related, for the issue of deploying Django itself with multiple databases, you may want to take a look at Djangostack. You can download a completely free installer that allows you to install Apache, Python, Django, etc. As part of the installation process we allow you to select which database you want to use (MySQL, SQLite, PostgreSQL). We use the installers extensively when automating deployments internally (they can be run in unattended mode).

Answer 7:

I have my file in an external directory. That way, it doesn’t get checked into source control, or over-written by a deploy. I put this in the file under my Django project, along with any default settings:

import sys
import os.path

def _load_settings(path):    
    print "Loading configuration from %s" % (path)
    if os.path.exists(path):
    settings = {}
    # execfile can't modify globals directly, so we will load them manually
    execfile(path, globals(), settings)
    for setting in settings:
        globals()[setting] = settings[setting]


Note: This is very dangerous if you can’t trust

Answer 8:

In addition to the multiple settings files mentioned by Jim, I also tend to place two settings into my file at the top BASE_DIR and BASE_URL set to the path of the code and the URL to the base of the site, all other settings are modified to append themselves to these.

BASE_DIR = "/home/sean/myapp/"
e.g. MEDIA_ROOT = "%smedia/" % BASEDIR

So when moving the project I only have to edit these settings and not search the whole file.

I would also recommend looking at fabric and Capistrano (Ruby tool, but it can be used to deploy Django applications) which facilitate automation of remote deployment.

Answer 9:

Well, I use this configuration:

At the end of
    from locale_settings import *
except ImportError:

And in
class Settings(object):

    def __init__(self):
        import settings
        self.settings = settings

    def __getattr__(self, name):
        return getattr(self.settings, name)

settings = Settings()


# Delete duplicate settings maybe not needed, but I prefer to do it.
del settings
del Settings

Answer 10:

I think it depends on the size of the site as to whether you need to step up from using SQLite, I’ve successfully used SQLite on several smaller live sites and it runs great.

Answer 11:

I use environment:

if os.environ.get('WEB_MODE', None) == 'production' :
   from settings_production import *
else :
   from settings_dev import *

I believe this is a much better approach, because eventually you need special settings for your test environment, and you can easily add it to this condition.

Answer 12:

So many complicated answers!

Every file comes with :

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

I use that directory to set the DEBUG variable like this (reaplace with the directoy where your dev code is):

    DEBUG = True

Then, every time the file is moved, DEBUG will be False and it’s your production environment.

Every time you need different settings than the ones in your dev environment just use:

    #Debug setting
    #Release setting

Answer 13:

This is an older post but I think if I add this useful library it will simplify things.

Use django-configuration


pip install django-configurations

Then subclass the included configurations.Configuration class in your project’s or any other module you’re using to store the settings constants, e.g.:

# mysite/

from configurations import Configuration

class Dev(Configuration):
    DEBUG = True

Set the DJANGO_CONFIGURATION environment variable to the name of the class you just created, e.g. in ~/.bashrc:


and the DJANGO_SETTINGS_MODULE environment variable to the module import path as usual, e.g. in bash:

export DJANGO_SETTINGS_MODULE=mysite.settings

Alternatively supply the --configuration option when using Django management commands along the lines of Django’s default --settings command line option, e.g.:

python runserver --settings=mysite.settings --configuration=Dev

To enable Django to use your configuration you now have to modify your or script to use django-configurations’ versions of the appropriate starter functions, e.g. a typical using django-configurations would look like this:

#!/usr/bin/env python

import os
import sys

if __name__ == "__main__":
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
    os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

    from import execute_from_command_line


Notice in line 10 we don’t use the common tool but instead

The same applies to your file, e.g.:

import os

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')
os.environ.setdefault('DJANGO_CONFIGURATION', 'Dev')

from configurations.wsgi import get_wsgi_application

application = get_wsgi_application()

Here we don’t use the default django.core.wsgi.get_wsgi_application function but instead configurations.wsgi.get_wsgi_application.

That’s it! You can now use your project with and your favorite WSGI enabled server.

Answer 14:

In fact you should probably consider having the same (or almost the same) configs for your development and production environment. Otherwise, situations like “Hey, it works on my machine” will happen from time to time.

So in order to automate your deployment and eliminate those WOMM issues, just use Docker.