Deploy Vercel no Hobby: previews podem sumir antes de 30 dias

Quem faz deploy Vercel no plano Hobby já não pode tratar o histórico de 30 dias como garantia de rollback. Desde 16 de setembro de 2026, uma equipe Hobby que ultrapassa o limite de 10GB de Deployment Storage pode ter um preview antigo ou um destino de rollback de produção removido imediatamente quando nenhuma exceção de retenção o protege.

O deploy que está em produção continua seguro. O mesmo vale para deploys com aliases que atendem aos critérios e para o preview mais recente de um branch Git ativo. A mudança atinge tudo o que fica fora desses grupos protegidos. Por isso, um protótipo pessoal pode seguir no ar enquanto um link antigo de revisão simplesmente deixa de funcionar.

Deploy Vercel no Hobby: os 30 dias deixaram de ser o mínimo

Retenção de deploy é a regra que determina por quanto tempo a Vercel mantém os arquivos gerados por cada deploy. São esses arquivos armazenados que permitem reabrir um preview antigo, promover uma build já testada sem refazê-la ou reverter a produção durante um incidente.

O intervalo normal de retenção do Hobby continua sendo de 30 dias. A novidade é a regra de limpeza aplicada acima do limite: quando a equipe passa de 10GB de Deployment Storage, um deploy desprotegido pode se tornar elegível para exclusão antes do fim desses 30 dias. Essa é a consequência prática da mudança. O histórico gratuito de deploys agora depende tanto do uso de armazenamento quanto das exceções abaixo.

Cada projeto Hobby recebe duas proteções para deploys recentes:

• Os 3 deploys mais recentes criados, de qualquer tipo
• Os 3 deploys de produção com status Ready mais recentes

Considere os dois critérios como um único conjunto, e não como seis vagas reservadas. Um deploy recente de produção pode aparecer nos dois grupos. Se os três deploys mais novos também forem as três versões de produção com status Ready mais recentes, somente esses mesmos três deploys ficam protegidos por essas duas regras.

Deploys de preview não contam mais com uma cota própria de previews recentes. Um preview fora dos três mais novos só permanece quando se encaixa em outra exceção.

O que a Vercel ainda protege

A forma mais simples de entender a regra é separar as proteções que dependem da data do deploy daquelas que dependem de como ele está sendo usado.

Essas exceções vêm das regras atuais de retenção de deploys da Vercel. Salvar apenas a URL de um deploy não é uma das proteções listadas. O que importa é a relação do deploy com um alias, um branch, o estado de produção ou sua posição entre os mais recentes.

Essa diferença muda um fluxo de trabalho comum. Você pode enviar um preview, mesclar o pull request e presumir que o link continuará útil até o fim do mês. Quando o branch deixa de estar ativo, a exceção que protegia seu preview mais recente termina. Se a equipe já estiver acima de 10GB e o deploy estiver fora dos dois conjuntos dos três mais recentes, o link pode perder seu destino antes do 30º dia.

Quem é afetado de verdade

O caso mais evidente é o de quem desenvolve sozinho e mantém vários protótipos pessoais. Projetos antigos podem ocupar espaço com artefatos de build enquanto os projetos ativos continuam recebendo deploys. Ao ultrapassar o limite da equipe, a Vercel pode limpar o histórico desprotegido de todo o time Hobby. Assim, o destino de rollback que importa pode pertencer justamente a um projeto que não recebe alterações há algum tempo.

Para quem trabalha com design e compartilha um conceito não comercial, o risco é outro. O preview atual de um branch de revisão aberto está protegido; o link mais antigo, usado para registrar uma decisão anterior de design, talvez não esteja. Se essa build exata precisar continuar disponível para consulta, ela deve receber um alias personalizado que cumpra os critérios ou outro plano de preservação antes que o branch seja fechado.

Quem usa deploys como uma prateleira de versões para rollback precisa conferir o conjunto recente de produção. Os 3 deploys de produção com status Ready mais recentes continuam protegidos, mas uma versão estável mais antiga não fica segura só por ter menos de 30 dias.

Freelancers, agências e empresas não devem usar a retenção como único critério para decidir sobre o upgrade. O Hobby é restrito a uso pessoal e não comercial. Projetos comerciais devem estar no Pro mesmo quando ocupam menos de 10GB. Portanto, a mudança no histórico de deploy apenas reforça uma decisão de plano que já existia.

Equipes Hobby abaixo de 10GB não entram no novo fluxo de limpeza imediata. Seus deploys continuam seguindo a política normal de 30 dias e suas exceções. Equipes Pro e Enterprise também ficam fora dessa mudança específica do Hobby. Seus períodos padrão de retenção e suas quantidades protegidas de deploys recentes são maiores.

Faça uma auditoria do histórico que ainda importa

Comece pelo nível da equipe. O limite de 10GB pertence ao time Hobby, mas as pistas úteis estão distribuídas entre os projetos.

1. 1

   Confira os dois medidores de armazenamento

   Selecione a equipe correta na Vercel, abra Usage e escolha Deployment Storage. Verifique tanto Deployment Storage, que inclui os artefatos de build e arquivos estáticos, quanto Functions Storage, que inclui os pacotes de funções. Abra Projects em cada métrica para descobrir quais projetos concentram a maior parte dos dados armazenados.

2. 2

   Anote os deploys que não podem ser perdidos

   Em cada projeto grande, abra Deployments. Registre o deploy atual de produção, a build de produção que seria usada de fato em um rollback, todas as URLs de preview ainda presentes em um fluxo de revisão ou aprovação e qualquer build antiga necessária para uma auditoria ou verificação de regressão. Essa lista representa o requisito; o feed de deploys é apenas o inventário.

3. 3

   Associe cada item importante a uma proteção

   Confira se cada item está entre os 3 últimos criados, entre os 3 deploys de produção com status Ready mais recentes, vinculado a um alias que atenda aos critérios ou definido como o preview mais recente de um branch ativo. Não conte os dois grupos de três separadamente quando o mesmo deploy aparecer em ambos.

4. 4

   Preserve a exceção ou preserve o código-fonte

   Mantenha o branch de revisão ativo enquanto seu preview mais recente ainda for necessário. Atribua um alias personalizado a um deploy essencial que não esteja em produção quando isso fizer sentido no fluxo de trabalho. Nos demais casos, garanta que o commit de origem, a configuração e os dados externos necessários para refazer a build estejam disponíveis fora do histórico de deploys.

5. 5

   Remova o armazenamento que não tem mais função

   Depois que os responsáveis confirmarem o que pode sair, remova aliases personalizados obsoletos e feche pull requests antigos pelo processo normal do repositório. Em seguida, abra a visualização Resources do maior deploy para procurar arquivos estáticos ou pacotes de Functions grandes demais. A página Usage consegue apontar um projeto, mas não identifica o arquivo, o deploy ou o pacote exato que gera o total.

O guia de otimização de armazenamento da Vercel recomenda comparar a mesma equipe, os dois indicadores de armazenamento, os mesmos projetos e o mesmo período de 30 dias depois de uma mudança. A limpeza por retenção e a redução dos artefatos de build resolvem problemas diferentes. A primeira diminui o histórico armazenado ao longo do tempo; a segunda reduz o tamanho dos novos deploys.

A limpeza e o Pro mudam partes diferentes da conta

Para um projeto pessoal e não comercial, a limpeza é a opção sem custo de assinatura. Você abre mão do histórico que já não tem utilidade, reduz o tamanho dos artefatos quando possível e permanece abaixo do limite do Hobby. O custo é operacional: haverá menos previews antigos para consultar e menos builds de produção disponíveis para rollback.

O Pro não é um upgrade de $0.10. No plano Pro, Deployment Storage e Functions Storage custam $0.10 por GB-mês cada. Portanto, manter 10GB de uma dessas métricas durante um mês inteiro custa $1 na tabela. Porém, o plano começa com uma taxa mensal de plataforma de $20, que inclui um assento com permissão de deploy e $20 em crédito mensal para uso de infraestrutura. Cada assento adicional de Owner ou Member com permissão de deploy acrescenta outros $20 por mês. Assentos Viewer são gratuitos.

A regra para decidir fica simples. Não compare “apagar o histórico” com “pagar $1 pelo armazenamento”. Compare a limpeza com o plano mensal completo de $20; depois, some cada pessoa adicional com permissão de deploy e verifique se o crédito incluído cobre o uso real de armazenamento e de outros recursos de infraestrutura da equipe. A análise completa dos preços da Vercel explica os demais componentes dessa fatura.

Para um protótipo pessoal, $20 por mês pode custar mais do que vale o histórico preservado. Em um projeto comercial, a elegibilidade do plano resolve a questão antes mesmo da retenção. Para uma empresa com uma única pessoa desenvolvedora que já precisa do Pro, os períodos maiores de retenção e as proteções adicionais para deploys recentes fazem parte do valor que já está sendo pago.

O que fazer na segunda-feira

Se a equipe Hobby estiver acima ou perto de 10GB, comece pela página Usage e identifique os projetos que mais ocupam Deployment Storage e Functions Storage. Depois, marque exatamente quais links de preview e destinos de rollback ainda cumprem uma função no negócio ou na revisão. Proteja esses itens de propósito e deixe o histórico sem função ser removido.

Se a equipe estiver bem abaixo de 10GB, não há uma limpeza emergencial a fazer. Ainda assim, considere a política normal de 30 dias, principalmente ao fechar um branch responsável por um preview que alguém continua usando.

Se o projeto for comercial, não trate a limpeza do Hobby como plano de longo prazo. Reserve no orçamento o valor integral do Pro, mantenha o acesso de deploy apenas para quem precisa, use assentos Viewer gratuitos para as demais pessoas e compare essa fatura com o custo de reconstruir um fluxo perdido de revisão ou rollback.

Para receber uma análise direta como esta por semana, assine a newsletter.