How to deploy static files

Servindo arquivos estáticos em produção

The basic outline of putting static files into production consists of two steps: run the collectstatic command when static files change, then arrange for the collected static files directory (STATIC_ROOT) to be moved to the static file server and served. Depending the staticfiles STORAGES alias, files may need to be moved to a new location manually or the post_process method of the Storage class might take care of that.

As with all deployment tasks, the devil’s in the details. Every production setup will be a bit different, so you’ll need to adapt the basic outline to fit your needs. Below are a few common patterns that might help.

Servindo o site e os arquivos estáticos de um mesmo servidor.

Se você quer servir arquivos estáticos do mesmo servidor que já está servindo seu site , o processo talvez se pareça com algo como:

Você irá provavelmente querer automatizar o processo, especialmente se você possuir múltiplos servidores web.

Servindo arquivos estáticos atráves de um servidor dedicado

Most larger Django sites use a separate web server – i.e., one that’s not also running Django – for serving static files. This server often runs a different type of web server – faster but less full-featured. Some common choices are:

A configuração destes servidores estão fora do escopo deste documento; verifique a respectiva documentação de cada um para instruções.

Já que seu servidor de arquivos estáticos não irão rodar um Django, você irá precisar modificar a estratégia para algo como:

  • Quando seus arquivos estáticos mudarem, execute collectstatic localmente.
  • Coloque seu STATIC_ROOT local no servidor de arquivo estático dentro do diretório que esta sendo servido. O rsync é uma opção comum para este passo já que ele precisa transferir somente as partes dos arquivos estáticos quesofreram mudanças.

Servindo arquivos estáticos de um serviço em nuvem ou CDN

Another common tactic is to serve static files from a cloud storage provider like Amazon’s S3 and/or a CDN (content delivery network). This lets you ignore the problems of serving static files and can often make for faster-loading web pages (especially when using a CDN).

Quando usar estes serviços, o processo básico será parecido como o acima, exceto que no lugar de usar o rsync para transferir seus arquivos estáticos para o servidor, você irá precisa transferir os arquivos estáticos para fornecedor do armazenamento ou CDN.

There’s any number of ways you might do this, but if the provider has an API, you can use a custom file storage backend to integrate the CDN with your Django project. If you’ve written or are using a 3rd party custom storage backend, you can tell collectstatic to use it by setting staticfiles in STORAGES.

Por exemplo, se você escreveu um backend de armazenamento para o S3 em myproject.storage.S3Storage você poderia ele com:

STORAGES = {
    # ...
    "staticfiles": {"BACKEND": "myproject.storage.S3Storage"}
}

Once that’s done, all you have to do is run collectstatic and your static files would be pushed through your storage package up to S3. If you later needed to switch to a different storage provider, you may only have to change staticfiles in the STORAGES setting.

Para detalhes sobre como escrever um destes backends, veja Como escrever uma classe de armazenamento customizada. Existem aplicações de terceiros disponíveis que fornecem backends de armazenamento para muitas APIs comuns de armazenamento comuns. Um bom começo é uma olhada geral no djangopackages.com.

Changed in Django 4.2:

The STORAGES setting was added.

Aprenda mais

Para detalhes completos sobre todas as configurações, comandos, tags de templates, e outras partes incluidas em django.contrib.staticfiles, veja a referencia de arquivos estáticos.

Back to Top