# documentación de Django - 1.10.7

# 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:

- Como usar Django con Apache y `mod_wsgi`
- Authenticating against Django’s user database from Apache
- How to use Django with Gunicorn
- How to use Django with uWSGI

## 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 server, namely the `runserver` command, reads 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.

Nota

Dado que las variables de entorno abarcan todo un proceso, esto no funciona cuando se tienen varios sitios Django corriendo en el mismo proceso. Esto sucede con 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.

Nota

Some third-party WSGI middleware do not call `close` on the response object after handling a request. In those cases the `request_finished` signal isn’t sent. This can result in idle connections to database and memcache servers.