What to Provision

A Good Basic Setup

One of the intimidating things about deploying a Django application is the number of decisions that need to be made.

Here are a recommended set of choices for deploying Django apps. Most of these choices have alternatives, and some are decided for you if you’re using a PaaS, but in the absence of a reason to use an alternative, these should work reasonably well in most cases.

Operating System
Ubuntu LTS server: Ubuntu because it’s stable, it’s free, and it’s popular among developers, so any Django or Python software is likely to work well on it. LTS because of the long support guarantee, and server since we don’t need costly graphical desktop environments on our servers.
Django version
The latest released version: because it will be supported by security fixes for the longest time, compared to any older version, and Django has a history of putting out pretty stable releases. (Maybe wait a couple of weeks after a new release to see if there’s a .1 release.)
Database

PostgreSQL: because it and MySQL are the most popular free databases, so it’s well supported, and MySQL is lacking some features. For example, MySQL cannot perform schema changes in transactions, so if a schema migration fails in the middle, your data could be left in an indeterminate state.

Sometimes there are reasons to use another database than PostgreSQL. Just be sure not to use SQLite, even though it’s very easy to set up. It’s not suited for production use.

Web server

Apache or nginx: both work well as front ends for Django applications.

It is important to have a web server handle incoming requests, rather than having them go directly to the Django application, for a couple of reasons:

  • Web servers are designed to efficiently process the load of incoming requests, and deal with the wide variety of web clients. That lets the WSGI server focus on hosting the Django application.
  • The Django application should never be used to serve static files in production. If the static files are not being served by another system, the web server is used to either serve the static files, or proxy the requests to something other than the Django application.
WSGI server

mod_wsgi with Apache, or gunicorn: Either of these work well.

The WSGI server provides a Python process to run your Django application.

mod_wsgi can be convenient if you are already be using Apache on the server for static files. Gunicorn is easier to configure and run.

In any case, never use runserver in production. It is not secure, and performs poorly.

Message queue server
RabbitMQ: because it’s stable and popular. Redis is also commonly used as a message queue server.
Schema migration
South: because it’s really the only choice available for schema migrations in Django.
RapidSMS Router
DatabaseRouter: because it has the most features.
Asynchronous task scheduler
Celery: see Using Celery for Scheduling Tasks.
Application settings
Applications settings should be shared between different environments as much as possible. Keeping settings files available to all developers through your version control system keeps all of the developers on the same page and allows new developers to get started on your project quickly. The Django Book covers managing settings.py files between environments within projects.

Server Setup Recommendations

These are some recommendations for setting up your server.

Fail2ban
install to detect and block some intrusion attempts
Firewall
Block any incoming traffic that isn’t needed by your application or server. Ubuntu provides the ufw tool which makes this easy.
Logwatch
Logwatch will check your system logs daily and email you a daily report. This is helpful for spotting unusual activity.
Automatic security updates
You can set up Ubuntu to automatically install security-related updates.
ntp
use ntp to keep system clock up to date