Running Django with Gunicorn – Best Practice

After checking out I’d say that the best way is using gunicorn + wsgi

$ gunicorn project.wsgi:application

It’s now both confirmed in gunicorn docs: if you run Django 1.4 or newer, it’s highly recommended to simply run your application with the WSGI interface using the gunicorn command and django as linked above.

It also avoids adding gunicorn as installed app, which means it’s not a requirement to install gunicorn to test your app which might be useful from time to time.

About Settings

The Django settings file to be used can be passed through an ENV variable, or customized in the wsgi.py file. I sometimes create several wsgi.py files if I have multiple settings (eg. multiple websites) that have to run from the same project – See Django Doc for more info.

A one-liner solution that does not require any new file from Carl’s comment:

DJANGO_SETTINGS_MODULE=project.settings.prod gunicorn project.wsgi:application

sounds like a nicer way (though I’ll probably end up writing it in some shell commands to make it easy to “remember”).

Gunicorn settings can be passed as -c settings_file, but I’m exploring other ways and will try to update this answer if I find any. Using environment variables seems a workaroud, but only for limited cases

In particular it would be nice to get/share some settings between django and gunicorn; gunicorn documentation says:

Currently, only Paster applications have access to framework
specific settings. If you have ideas for providing settings to WSGI
applications or pulling information from Django’s settings.py feel
free to open an issue to let us know.

(Update: haven’t found any smarter way, but after all env variables are enough for my most-common cases).

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)