---
title: "Django 6.0: Tarefas em Background, CSP e Mais"
url: "https://python.dev.br/blog/django-6-novidades-tarefas-background/"
markdown_url: "https://python.dev.br/blog/django-6-novidades-tarefas-background.MD"
description: "Conheça as novidades do Django 6.0: tarefas em background, CSP nativo, template partials, email moderno e quando ainda usar Celery em produção."
date: "2026-04-29"
author: "Equipe Python Brasil"
---
# Django 6.0: Tarefas em Background, CSP e Mais
Conheça as novidades do Django 6.0: tarefas em background, CSP nativo, template partials, email moderno e quando ainda usar Celery em produção.
O Django 6.0, lançado em dezembro de 2025, trouxe mudanças que desenvolvedores Python pediam há anos. O destaque absoluto é o **framework nativo de tarefas em background** — algo que antes exigia bibliotecas externas como Celery para até os casos mais simples. Além disso, o suporte embutido a **Content Security Policy (CSP)**, os **template partials** e a adoção da API moderna de email tornam essa a atualização mais significativa do Django em muito tempo.
Neste artigo, você vai entender cada novidade com exemplos práticos, ver como migrar seus projetos e decidir quando a tarefa nativa basta ou quando ainda faz sentido usar [Celery](/glossario/celery/), Redis e workers separados. Se você ainda está decidindo entre frameworks, veja nosso [comparativo Django vs Flask](/blog/django-vs-flask/) para entender onde cada um brilha.
## Framework de tarefas em background
Até o Django 5.x, executar código fora do ciclo request-response exigia soluções externas. O Celery, o Dramatiq ou filas com [Redis](/blog/python-e-redis/) eram praticamente obrigatórios para qualquer aplicação que precisasse enviar emails, processar dados ou gerar relatórios de forma assíncrona.
O Django 6.0 muda isso com o decorator `@task` e o método `enqueue()`:
```python
from django.core.mail import send_mail
from django.tasks import task
@task
def notificar_usuarios(emails, assunto, mensagem):
"""Envia email para uma lista de usuários."""
return send_mail(assunto, mensagem, None, emails)
# Em qualquer view ou serviço, enfileirar a tarefa
notificar_usuarios.enqueue(
emails=["usuario@exemplo.com.br"],
assunto="Novo relatório disponível",
mensagem="Seu relatório mensal foi gerado com sucesso.",
)
```
A configuração é feita pela setting `TASKS`, que define o backend de execução. O Django inclui dois backends embutidos para desenvolvimento e testes, enquanto backends de produção como o django-tasks-database processam as tarefas via workers externos.
O ponto importante para produção é não confundir API nova com mágica operacional. Tarefas em background continuam precisando de processo executor, política de retry, logs, métrica de fila e uma estratégia para falhas. Para envio simples de email, o recurso nativo reduz bastante a complexidade. Para importação grande, geração de relatório, sincronização de CRM ou processamento que não pode se perder, compare com [FastAPI Background Tasks, Celery e Redis](/blog/fastapi-background-tasks-celery-redis-2026/) antes de decidir.
### Exemplo prático: processamento de imagens
Imagine um endpoint que recebe uploads de imagens e precisa gerar thumbnails. Antes, a view ficaria lenta esperando o processamento. Agora:
```python
from django.tasks import task
from PIL import Image
import os
@task
def gerar_thumbnail(caminho_imagem, largura=300):
"""Gera thumbnail de uma imagem enviada pelo usuário."""
img = Image.open(caminho_imagem)
ratio = largura / img.width
altura = int(img.height * ratio)
img_redimensionada = img.resize((largura, altura))
nome_base, ext = os.path.splitext(caminho_imagem)
caminho_thumb = f"{nome_base}_thumb{ext}"
img_redimensionada.save(caminho_thumb)
return caminho_thumb
# Na view, retorno instantâneo para o usuário
def upload_view(request):
arquivo = request.FILES["imagem"]
caminho = salvar_arquivo(arquivo)
gerar_thumbnail.enqueue(caminho_imagem=caminho)
return JsonResponse({"status": "processando"})
```
Se você já trabalha com [programação assíncrona em Python](/blog/python-async-await/), vai notar que as tarefas em background complementam o async/await — enquanto o async otimiza I/O dentro de uma request, as tarefas em background movem trabalho pesado para fora do ciclo HTTP por completo.
## Content Security Policy nativo
Ataques de injeção de conteúdo como XSS continuam entre os mais comuns na web. O Django 6.0 traz o `ContentSecurityPolicyMiddleware`, que adiciona headers CSP automaticamente, sem depender de pacotes como django-csp.
A configuração usa as settings `SECURE_CSP` e `SECURE_CSP_REPORT_ONLY`:
```python
# settings.py
from django.utils.csp import CSP
MIDDLEWARE = [
"django.middleware.security.SecurityMiddleware",
"django.middleware.csp.ContentSecurityPolicyMiddleware",
# ... demais middlewares
]
SECURE_CSP = {
"default-src": [CSP.SELF],
"script-src": [CSP.SELF, CSP.NONCE],
"style-src": [CSP.SELF, "https://fonts.googleapis.com"],
"img-src": [CSP.SELF, "https:"],
"font-src": [CSP.SELF, "https://fonts.gstatic.com"],
}
```
O header gerado será algo como:
```
default-src 'self'; script-src 'self' 'nonce-abc123'; style-src 'self' https://fonts.googleapis.com; img-src 'self' https:; font-src 'self' https://fonts.gstatic.com
```
Nos templates, o nonce é disponibilizado pelo context processor `csp()`:
```html
```
Para quem mantém aplicações em produção, esse recurso complementa as práticas que discutimos no artigo sobre [segurança em aplicações Python](/blog/seguranca-em-aplicacoes-python/). O CSP nativo elimina uma dependência externa e garante proteção consistente desde o início do projeto.
## Template partials
Quem já trabalhou com componentes em frameworks JavaScript sabe a frustração de, no Django, precisar criar arquivos separados para cada fragmento reutilizável de template. O Django 6.0 resolve isso com as tags `{% partialdef %}` e `{% partial %}`:
```html
{% partialdef card_produto %}
{% endpartialdef %}
{% for produto in produtos %}
{% partial card_produto %}
{% endfor %}
```
O partial pode ser referenciado de outros templates usando a sintaxe `template_name#partial_name`:
```html
{% for produto in destaques %}
{% include "produto/lista.html#card_produto" %}
{% endfor %}
```
Essa abordagem funciona com `get_template()`, `render()` e `{% include %}`, permitindo organizar componentes visuais sem fragmentar seus templates em dezenas de arquivos. Se você adota [design patterns em Python](/blog/design-patterns-python/), os partials seguem o princípio DRY de forma natural.
## API moderna de email
O Django 6.0 migrou do módulo legado `email.mime` para a API moderna `email.message.EmailMessage` do Python, introduzida na versão 3.6. A mudança traz:
- Interface mais limpa e intuitiva
- Melhor suporte a Unicode
- Compatibilidade com as práticas atuais do Python
```python
from django.core.mail import EmailMessage
email = EmailMessage(
subject="Confirmação de cadastro",
body="Bem-vindo ao nosso serviço!",
from_email="contato@exemplo.com.br",
to=["novo_usuario@email.com"],
)
# Novo: aceita objetos MIMEPart diretamente
email.attach("relatorio.pdf", conteudo_pdf, "application/pdf")
email.send()
```
Se o seu projeto já automatiza o envio de emails, confira nosso guia de [automação de emails com Python](/blog/python-para-automacao-de-emails/) para combinar a nova API com templates dinâmicos.
## Outras novidades relevantes
### AsyncPaginator
Para views assíncronas, o Django 6.0 inclui `AsyncPaginator` e `AsyncPage`, eliminando a necessidade de wraps em `sync_to_async`:
```python
from django.core.paginator import AsyncPaginator
paginator = AsyncPaginator(queryset, per_page=25)
page = await paginator.aget_page(numero_pagina)
```
### forloop.length nos templates
A variável `forloop.length` agora está disponível dentro de loops `{% for %}`, sem precisar de filtros ou tags extras:
```html
{% for item in lista %}
Item {{ forloop.counter }} de {{ forloop.length }}
{% endfor %}
```
### StringAgg multiplataforma
O aggregate `StringAgg`, antes exclusivo do PostgreSQL, agora funciona com SQLite, MySQL e Oracle. Quem trabalha com [PostgreSQL](/blog/python-e-postgresql/) ou [SQLite](/blog/python-e-banco-de-dados-sqlite/) pode usar a mesma query em ambos.
## Como migrar para o Django 6.0
Antes de atualizar, verifique estes pontos:
1. **Versão do Python**: Django 6.0 exige Python 3.12 ou superior. Se você ainda usa 3.10 ou 3.11, atualize primeiro — veja as [novidades do Python 3.14](/blog/python-3-14-novidades-recursos/) para entender o que ganhou
2. **Banco de dados**: MariaDB 10.5 não é mais suportado (mínimo 10.6)
3. **Testes**: execute sua suite de [testes unitários](/blog/testes-unitarios-python/) antes e depois da migração
4. **Dependências**: verifique compatibilidade dos pacotes terceiros com Django 6.0
```bash
# Atualizar Django no seu ambiente virtual
pip install --upgrade Django==6.0
# Ou com uv
uv pip install Django==6.0
# Verificar problemas de compatibilidade
python -m django check --deploy
```
Para gerenciar seu ambiente de desenvolvimento, recomendamos o [uv](/blog/uv-gerenciador-pacotes-python/) como gerenciador de pacotes moderno, ou consulte nosso guia sobre [ambientes virtuais](/blog/virtual-environments-python/).
Depois da atualização, valide também a parte operacional. Rode `python -m django check --deploy`, execute a suite de [testes com pytest](/guias/testes-com-pytest/), publique uma tarefa de exemplo em ambiente de staging e confira se worker, logs e alertas registram o ciclo completo. Se sua aplicação já usa filas, este é um bom momento para revisar [observabilidade com OpenTelemetry em Python](/blog/opentelemetry-python-observabilidade/) e garantir que tarefas, views e integrações externas compartilhem IDs de correlação.
## Django 6.0 e o ecossistema web Python
O Django continua evoluindo em direção a uma experiência mais integrada. As tarefas em background reduzem a dependência de filas externas para casos simples, enquanto o CSP nativo e os template partials mostram que o framework absorve necessidades reais da comunidade.
Se o seu projeto exige APIs REST de alta performance, vale comparar com o [FastAPI](/blog/apis-rest-com-fastapi/), que segue uma abordagem async-first. Para projetos menores ou microsserviços, o [Flask](/blog/django-vs-flask/) continua relevante. Desenvolvedores que exploram outras linguagens para web encontram abordagens similares em Go com Gin e Echo e em Kotlin com Ktor e Spring Boot, cada um com filosofias diferentes sobre frameworks web.
Se você quer transformar essa atualização em diferencial profissional, conecte o tema ao seu [portfólio Python](/carreira/projetos-portfolio-python/) e ao checklist de [teste técnico Python](/carreira/teste-tecnico-python/): uma aplicação Django com upload, tarefa em background, status do processamento, testes e deploy documentado demonstra muito mais maturidade do que apenas uma view CRUD.
Se você quer explorar o paralelismo real que o Python 3.14 trouxe para complementar as tarefas em background do Django, confira nosso artigo sobre [subinterpreters e PEP 734](/blog/python-3-14-subinterpreters-pep-734/).
## Perguntas frequentes
### O Django 6.0 substitui completamente o Celery?
Não. O framework de tarefas em background do Django 6.0 é ideal para tarefas simples como envio de emails e processamento leve. Para cenários complexos com retry, scheduling avançado, chains e workflows distribuídos, o Celery continua sendo a melhor opção. Se você está comparando isso com APIs modernas, veja o guia de [FastAPI Background Tasks, Celery e Redis](/blog/fastapi-background-tasks-celery-redis-2026/).
### Preciso reescrever meus templates para usar partials?
Não. Os template partials são opcionais e retrocompatíveis. Você pode adotá-los gradualmente nos templates que mais se beneficiam de reutilização, sem alterar o que já funciona.
### O CSP nativo do Django 6.0 substitui o django-csp?
Sim, para a maioria dos casos. O middleware embutido cobre as necessidades mais comuns de Content Security Policy. Projetos com configurações muito específicas podem continuar usando o django-csp, mas a recomendação oficial é migrar para o suporte nativo.
### Quais versões do Python são compatíveis com o Django 6.0?
O Django 6.0 suporta Python 3.12, 3.13 e 3.14. O suporte a Python 3.10 e 3.11 foi removido. Se você ainda usa essas versões, precisará atualizar o Python antes de migrar o Django.