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

A principal plataforma de deploy do Django é [WSGI](https://wsgi.readthedocs.io/en/latest/), o padrão Python para servidores web e aplicações.

Django’s [`startproject`](/pt-br/4.2/ref/django-admin/#django-admin-startproject) management command sets up a minimal default
WSGI configuration for you, which you can tweak as needed for your project,
and direct any WSGI-compliant application server to use.

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

- [Como usar o Django com o Gunicorn](/pt-br/4.2/howto/deployment/wsgi/gunicorn/)
- [Como usar Django com uWSGI](/pt-br/4.2/howto/deployment/wsgi/uwsgi/)
- [Como usar o Django com Apache e `mod_wsgi`](/pt-br/4.2/howto/deployment/wsgi/modwsgi/)
- [How to authenticate against Django’s user database from Apache](/pt-br/4.2/howto/deployment/wsgi/apache-auth/)

## 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/4.2/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.

Servidores WSGI obtém o caminho para o executável da `application` da sua configuração. O servidor embutido do Django, comando denominado [`runserver`](/pt-br/4.2/ref/django-admin/#django-admin-runserver), lê isso da definição [`WSGI_APPLICATION`](/pt-br/4.2/ref/settings/#std-setting-WSGI_APPLICATION). Por padrão, está definido como  `<project_name>.wsgi.application`, o que aponta para o executável de `application` no  `<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/4.2/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/4.2/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

To apply [**WSGI middleware**](https://peps.python.org/pep-3333/#middleware-components-that-play-both-sides) you can 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)
```

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.