How to deploy with WSGI¶
Django’s primary deployment platform is WSGI, the Python standard for web servers and applications.
Django’s startproject management command sets up a simple default WSGI configuration for you, which you can tweak as needed for your project, and direct any WSGI-compliant application server to use.
Django includes getting-started documentation for the following WSGI servers:
The application object¶
The key concept of deploying with WSGI is the application callable which the application server uses to communicate with your code. It’s commonly provided as an object named application in a Python module accessible to the server.
The startproject command creates a file <project_name>/wsgi.py that contains such an application callable.
It’s used both by Django’s development server and in production WSGI deployments.
WSGI servers obtain the path to the application callable from their configuration. Django’s built-in servers, namely the runserver and runfcgi commands, read it from the WSGI_APPLICATION setting. By default, it’s set to <project_name>.wsgi.application, which points to the application callable in <project_name>/wsgi.py.
Configuring the settings module¶
When the WSGI server loads your application, Django needs to import the settings module — that’s where your entire application is defined.
Django uses the DJANGO_SETTINGS_MODULE environment variable to locate the appropriate settings module. It must contain the dotted path to the settings module. You can use a different value for development and production; it all depends on how you organize your settings.
If this variable isn’t set, the default wsgi.py sets it to mysite.settings, where mysite is the name of your project. That’s how runserver discovers the default settings file by default.
Since environment variables are process-wide, this doesn’t work when you run multiple Django sites in the same process. This happens with mod_wsgi.
To avoid this problem, use mod_wsgi’s daemon mode with each site in its own daemon process, or override the value from the environment by enforcing os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings" in your wsgi.py.
Applying WSGI middleware¶
To apply WSGI middleware you can simply wrap the application object. For instance you could add these lines at the bottom of wsgi.py:
from helloworld.wsgi import HelloWorldApplication application = HelloWorldApplication(application)
You could also replace the Django WSGI application with a custom WSGI application that later delegates to the Django WSGI application, if you want to combine a Django application with a WSGI application of another framework.
Some third-party WSGI middleware do not call close on the response object after handling a request — most notably Sentry’s error reporting middleware up to version 2.0.7. In those cases the request_finished signal isn’t sent. This can result in idle connections to database and memcache servers.
Upgrading from Django < 1.4¶
If you’re upgrading from Django 1.3.x or earlier, you don’t have a wsgi.py file in your project.
You can simply add one to your project’s top-level Python package (probably next to settings.py and urls.py) with the contents below:
import os os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings") from django.core.wsgi import get_wsgi_application application = get_wsgi_application()
The os.environ.setdefault line just sets the default settings module to use, if you haven’t explicitly set the DJANGO_SETTINGS_MODULE environment variable. You’ll need to edit this line to replace mysite with the name of your project package, so the path to your settings module is correct.
Also add WSGI_APPLICATION = "mysite.wsgi.application" in your settings, so that runserver finds your application callable. Don’t forget to replace mysite with the name of your project in this line.