This is skeleton for Django settings as directory directory.

Features include:

  1. Separation of sensitive & safe settings.
  2. Single point for version controlled project defaults: If you exclude from your VCS you will still be able to track all safe configuration changes like adding new application or changing context processors.
  3. Common settings base for one-database & one-codebase multiple sites site.
  4. Testing near-zero-configuration.
  5. Ability to work with same settings but different databases on production & staging without worying about commiting staging credentials to production, etc.



  • to
  • to

and configure them.

You can add more files like or, and so on...

Sample usage:

# runing several sites on same engine:
./ runfcgi --settings=settings.whatever --socket=...
./ runfcgi --settings=settings.sitename --socket=...
./ runfcgi --settings=settings.domain --socket=...


Sensitive settings

I have habit of separating sensitive configuration settings like database passwords, api keys, etc into separate file.

Reason? Well, sometimes even with private repositories you work with freelance developers or you just don't trust that new guy enough to give him access to production database.

This is where this skeleton comes handy, just add <your project name>/settings/ file to your .hgignore and remember to put new sensitive data there.

You will have to come with other way of deploying this file to production machines like adding it fabric or puppet configuration.

Multiple sites

You can also with minimal effort handle multiple sites on same engine, like:

SITE_ID       = 1

SITE_ID       = 2


Additional file is there for adding anything extra to your management commands without need to call --settings=.....

Beside obvious speed up (typing) feature it can be used with multiple site setups to provide single point of "upgrade", consider this:

You have four apps "app1".."app4", and three sites "site1".."site3".

All your sites are using "app4" but app1 is used only in site1, app2 only in site2 and app3 only in site3.

Now let's assume that you have some cascading migration dependencies.

You can simply add all four apps to INSTALLED_APPS += ... and migrate with simple:

./ migrate


You can significantly speed up testing by using:

# runing tests with in-memory database like sqlite:
./ test <sometests> --settings=settings.test