Vercel agora cobra pelo histórico de deployments que garante rollback instantâneo

A Vercel anunciou no changelog de 22 de agosto de 2026 o Deployment Storage, o mecanismo que mantém disponíveis os arquivos gerados por cada deployment (páginas, functions e assets) para que times possam inspecionar versões anteriores e, principalmente, fazer rollback quando algo dá errado em produção. A novidade tem dois lados: a garantia de que o rollback continua funcionando e um novo item de cobrança na fatura.

O que exatamente fica armazenado

Todo deploy na Vercel produz um conjunto de artefatos: o HTML↳HTML45 conteúdosA importância do HTML e CSS para quem trabalha com UI Design e Design SystemProduto & UX · dez 2024Como hostear seu site HTML gratuitamente com GitHub PagesDev (Back & Front) · jun 2025SQL Server – Como criar um versionamento de código das suas Stored Procedures em HTML e com comentários da alteraçãoData · nov 2020Ver tudo em Dev (Back & Front) → das páginas, os bundles das Serverless/Edge Functions e os assets estáticos. O Deployment Storage é o espaço que guarda esses arquivos após o build. Sem eles preservados, não há para onde voltar: um rollback nada mais é do que reapontar os domínios do projeto para os artefatos de um deploy antigo que ainda existe.

É por isso que a Vercel deixa explícito na documentação que não dá para reverter para um deployment que já foi apagado. Se a política de retenção removeu aquele build, a opção de rollback simplesmente some. Essa é a mudança mental importante: o histórico de deploys deixou de ser algo "que está lá de graça para sempre" e passou a ser um recurso com custo e ciclo de vida configurável.

Como funciona o Instant Rollback na prática

O fluxo que a Vercel descreve é direto e não exige rebuild. Quando um deploy de produção sobe com um bug ou uma mudança indesejada:

1. Abra o projeto no dashboard.
2. Clique em Instant Rollback no tile de Production Deployment.
3. Escolha um deployment de produção anterior na lista.

A Vercel então reaponta os domínios para aquele deployment imediatamente. Como os artefatos já estão prontos e armazenados, não há etapa de compilação: por isso a promessa de restaurar a versão anterior "em segundos". Para quem opera produção, essa diferença é decisiva. Refazer um build de um projeto Next.js grande pode levar minutos; reapontar para um artefato existente é praticamente instantâneo, o que reduz drasticamente o MTTR (tempo médio de recuperação) durante um incidente.

Na prática, isso substitui a estratégia manual de "dar git revert e esperar o pipeline rodar de novo" nos casos em que o objetivo é apenas voltar ao estado bom conhecido o mais rápido possível. O rollback trata o problema no nível de infraestrutura, enquanto o revert no código pode vir depois, com calma.

O que muda na fatura

Aqui está a parte que exige atenção de quem controla custos em real. O Deployment Storage passa a ser cobrado a US$ 0,10 por GB por mês. Os detalhes anunciados:

• Times Hobby incluem até 10 GB sem custo.
• Times já existentes continuam com a precificação atual, sem mudança na conta "por enquanto" (a Vercel usa a expressão "at this time", ou seja, é uma transição, não uma isenção permanente).
• A página de Usage passa a mostrar Deployment Storage e Functions Storage separados por projeto, o que ajuda a identificar quem está inflando o armazenamento.

Para dar dimensão: US$ 0,10/GB/mês parece barato isoladamente, mas o volume acumula rápido em projetos com builds frequentes e output pesado. Um time que faz dezenas de deploys por dia, cada um com bundles gordos de functions e assets, pode ver o armazenamento crescer de forma silenciosa. Como o câmbio pesa para o dev brasileiro, vale acompanhar a página de Usage antes que o número surpreenda no fechamento do mês.

Controlando o custo com a política de retenção

A alavanca principal é a Deployment Retention Policy. Ela permite definir por quanto tempo cada categoria de deployment fica disponível:

• Pre-Production (previews)
• Production
• Canceled
• Errored

O trade-off é claro e a própria Vercel o resume: retenção mais curta significa menos armazenamento (e menos custo), mas você não consegue fazer rollback para um deployment que já foi excluído. Ou seja, é um equilíbrio entre economia e a janela de segurança que você quer manter para produção.

Uma configuração sensata para a maioria dos times: manter deployments de produção por um período mais longo (a janela real em que você poderia precisar reverter, algo como semanas), e ser agressivo cortando previews, cancelados e com erro, que raramente têm valor de rollback e são justamente os que acumulam lixo. Deploys errored, em especial, costumam não servir para nada além de diagnóstico imediato.

Reduzindo o tamanho de cada deploy

Além da retenção, a Vercel sugere atacar o problema na origem, deixando cada deployment menor:

• Enxugar o output directory, removendo arquivos que não precisam ser servidos.
• Mover arquivos grandes para o Vercel Blob, em vez de embuti-los no deployment.
• Reduzir o tamanho do bundle das Functions, o que, de quebra, melhora cold start e performance percebida.

Esse último ponto conecta armazenamento com performance: bundles menores custam menos para guardar e sobem mais rápido em produção. É um daqueles casos em que otimizar por um motivo (custo) traz benefício colateral em outro (latência).

Quando isso não é vantagem

Para um projeto pessoal pequeno em conta Hobby, os 10 GB inclusos provavelmente cobrem tudo e o recurso é puro ganho. O ponto de atenção é para times médios e grandes com CI/CD↳CI/CD23 conteúdosCI/CD Mobile: o caos invisível que separa times comuns de times de alta performanceDev (Back & Front) · abr 2026Lambda: implementando com GitLab CI/CD e Terraform para Integração SFTP, S3 e Databricks em GoDev (Back & Front) · nov 2023Publicando sua aplicação Web Python no WebApp do Azure e configurando o CI/CD da sua aplicaçãoDevSecOps · abr 2019Ver tudo em DevSecOps → intenso: o Deployment Storage transforma um comportamento que era gratuito e implícito em uma linha de custo que precisa ser gerenciada ativamente. Ignorar a política de retenção padrão pode significar pagar por meses de previews que ninguém vai reabrir.

A recomendação prática é revisar a Usage page por projeto, ajustar a retenção logo agora enquanto a cobrança está em transição para times existentes, e tratar o tamanho do output como métrica de saúde do projeto, e não como detalhe. Os detalhes completos estão no changelog e na documentação da Vercel linkados na fonte.

Fonte: Vercel Changelog