Django 6.0: Tarefas em Background, CSP e Mais

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. 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 e ver como migrar seus projetos. Se você ainda está decidindo entre frameworks, veja nosso comparativo 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 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():

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.

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:

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

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

<script nonce="{{ csp_nonce }}">
    console.log("Script autorizado pelo CSP");
</script>

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. 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 %}:

<!-- templates/produto/lista.html -->

{% partialdef card_produto %}
<div class="card">
    <h3>{{ produto.nome }}</h3>
    <p class="preco">R$ {{ produto.preco }}</p>
    <a href="{% url 'produto_detalhe' produto.id %}">Ver detalhes</a>
</div>
{% endpartialdef %}

<div class="grid">
    {% for produto in produtos %}
        {% partial card_produto %}
    {% endfor %}
</div>

O partial pode ser referenciado de outros templates usando a sintaxe template_name#partial_name:

<!-- templates/home.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, 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

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

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:

{% for item in lista %}
    <p>Item {{ forloop.counter }} de {{ forloop.length }}</p>
{% endfor %}

StringAgg multiplataforma

O aggregate StringAgg, antes exclusivo do PostgreSQL, agora funciona com SQLite, MySQL e Oracle. Quem trabalha com PostgreSQL ou 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 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 antes e depois da migração
4. Dependências: verifique compatibilidade dos pacotes terceiros com Django 6.0

# 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 como gerenciador de pacotes moderno, ou consulte nosso guia sobre ambientes virtuais.

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, que segue uma abordagem async-first. Para projetos menores ou microsserviços, o 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 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.

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.

Preciso reescrever meus templates para usar partials?

Nao. Os template partials sao opcionais e retrocompativeis. Voce pode adota-los gradualmente nos templates que mais se beneficiam de reutilizacao, sem alterar o que ja 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 configuracoes muito especificas podem continuar usando o django-csp, mas a recomendacao oficial e migrar para o suporte nativo.

Quais versoes do Python sao 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 voce ainda usa essas versoes, precisara atualizar o Python antes de migrar o Django.