---
title: "Como implantar com WSGI"
version: 1.9
locale: pt-br
source: https://docs.djangoproject.com/pt-br/1.9/howto/deployment/wsgi/
canonical: https://djangodocs.dev/pt-br/1.9/howto/deployment/wsgi/
---
# Como implantar com WSGI

A principal plataforma de implantação do Django é [WSGI](http://www.wsgi.org), o padrão Python para servidores web e aplicações.

O comando de gerenciamento do Django [`startproject`](/pt-br/1.9/ref/django-admin/#django-admin-startproject) define uma configuração  WSGI simples padrão para você, que você pode ajustar conforme necessário para o seu projeto , e direcionar qualquer servidor de aplicações compatível com WSGI para uso.

O Django inclui documentação básica para os seguintes seervidores WSGI:

- [Como usar o Django com Apache e `mod_wsgi`](/pt-br/1.9/howto/deployment/wsgi/modwsgi/)
- [Autenticação do usuário Django vindo do Apache.](/pt-br/1.9/howto/deployment/wsgi/apache-auth/)
- [Como usar o Django com o Gunicorn](/pt-br/1.9/howto/deployment/wsgi/gunicorn/)
- [Como usar Django com uWSGI](/pt-br/1.9/howto/deployment/wsgi/uwsgi/)

## O objeto `Application`

O conceito chave para implantação com WSGI é o executável `application` o qual o servidor de aplicação usa para se comunicar com seu código. Isso é comumente fornecido como um objeto chamado `application` em um módulo Python acessível ao servidor.

O comando [`startproject`](/pt-br/1.9/ref/django-admin/#django-admin-startproject) cria um arquivo  `<project_name>/wsgi.py` que contém a tal `application` executável.

Ele é usado tanto para o servidor de desenvolvimento do Django quanto para a implantação WSGI para produção.

WSGI servers obtain the path to the `application` callable from their
configuration. Django’s built-in server, namely the [`runserver`](/pt-br/1.9/ref/django-admin/#django-admin-runserver)
command, reads it from the [`WSGI_APPLICATION`](/pt-br/1.9/ref/settings/#std-setting-WSGI_APPLICATION) setting. By default, it’s
set to `<project_name>.wsgi.application`, which points to the `application`
callable in `<project_name>/wsgi.py`.

## Configurando o módulo de definições.

QUando o servidor WSGI carrega sua aplicação, o Django precisa importar o módulo de definições que é onde toda a sua aplicação é definida.

O Django usa a variável de ambiente [`DJANGO_SETTINGS_MODULE`](/pt-br/1.9/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) para localizar o módulo de definições apropriado. Este deve conter um caminho pontuado para o módulo de definições. Você pode usar um valor diferente para desenvolvimento e produção; Tudo depende de como você organiza suas definições.

Se essa variáve não está setada, o padrão `wsgi.py` define isso como `mysite.settings`, onde `mysite` é o nome do seu projeto. Assim é o padrão de como o [`runserver`](/pt-br/1.9/ref/django-admin/#django-admin-runserver) descobre o arquivo de definições padrão.

> **Note**
>
> Uma vez que as variáveis de ambiente são para todo o processo, isso não funciona quando você executa múltiplos Django sites  no mesmo processo. Isso acontece com mod\_wsgi.
>
> Para evitar este problema, use o daemon do mod\_wsgi com cada site em seu próprio processo, ou substitua  o valor do ambiente forçando `os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"` no seu `wsgi.py`.

## Aplicando o middleware WSGI

Pra aplicar o [WSGI middleware](https://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides) você pode simplesmente envolver o objeto da aplicação. Por exemplo, você pode adicionar essas linhas no final do  `wsgi.py`:

```
from helloworld.wsgi import HelloWorldApplication
application = HelloWorldApplication(application)
```

Poderia também substituir a aplicação WSGI Django por uma aplicação WSGI que mais tarde delega à aplicação WSGI Django, se quiser combinar uma aplicação Django com uma aplicação WSGI de um outro framework.

> **Note**
>
> Algumas middleware WSGI de terceiros não chamam `close` no objeto de resposta depois de manipular um request. Nestes casos o sinal [`request_finished`](/pt-br/1.9/ref/signals/#django.core.signals.request_finished) não é enviado. Isso pode resultar em conexões inativas no banco e em servidores memcache.