Different methods to deploy Django project and their pros and cons?

Question

I am quite a noob when it comes to deploying a Django project. I'd like to know what are the various methods to deploy Django project and which one is the most preferred.

Answer 1

The Django documentation lists Apache/mod_wsgi, Apache/mod_python and FastCGI etc.

mod_python is deprecated now, one should use mod_wsgi instead.

Django with mod_wsgi is easy to setup, but:

• you can only use one python version at a time [edit: you even can only use the python version mod_wsgi was compiled for]
• [edit: seems if I'm wrong on mod_wsgi not supporting virtualenv: it does]

So for multiple sites (targeting different django/python versions) on a server mod_wsgi is not the best solution.

FastCGI can be used with virtualenv, also with different python versions, as you run it with

./manage.py runfcgi …

and then configure your webserver to use this fcgi interface.

The new, hot stuff about django deployment seems to be gunicorn. It's a webserver that implements wsgi and is typically used as backend with a "big" webserver as proxy.

Deployment with gunicorn feels a lot like fcgi: you run a process doing the django processing stuff with manage.py, and a webserver as frontend to the world.

But gunicorn deployment has some advantages over fcgi:

• speed - I didn't find the sources, but benchmarks say fcgi is not as fast as the f suggests
• config files, for fcgi you must do all configuration on the commandline when executing the manage.py command. This comes unhandy when running multiple django instances via an init.d (unix-like OS' system service startup). It's always the same cmdline, with just different configuration files
• gunicorn can drop privileges: no need to do this in your init.d script, and it's easy to switch to one user per django instance
• gunicorn behaves more like a daemon: writing pidfile and logfile, forking to the background etc. makes again using it in an init.d script easier.

Thus, I would suggest to use the gunicorn solution, unless you have a single site on a single server with low traffic, than you could use the wsgi solution. But I think in the long run you're more happy with gunicorn.

If you have a django only webserver, I would suggest to use nginx as frontendproxy, as it's the best performing (again this is based on benchmarks I read in some blogposts - don't have the url anymore). Personally I use apache as frontendproxy, as I need it for other sites hosted on the server.

A simple setup instruction for django deployment could be found here: http://ericholscher.com/blog/2010/aug/16/lessons-learned-dash-easy-django-deployment/

My init.d script for gunicorn is located at github: https://gist.github.com/753053

Unfortunately I did not yet blog about it, but an experienced sysadmin should be able to do the required setup.

Answer 2

Use the Nginx/Apache/mod-wsgi and you can't go wrong.

If you prefer a simple alternative, just use Apache.

There is a very good deployment document: http://lethain.com/entry/2009/feb/13/the-django-and-ubuntu-intrepid-almanac/