Vercel Sandbox dobra o espaço para jobs maiores de agentes

A mudança mais útil no Vercel Sandbox não é apenas “64 GB”. É a possibilidade de um job de repositório que antes esbarrava no limite de 32 GB terminar agora em uma única máquina, sem precisar de cortes, divisões ou migração para outro ambiente.

Em 11 de setembro de 2026, a Vercel dobrou o armazenamento de trabalho padrão de todos os Sandboxes, de 32 GB para 64 GB.

Vercel Sandbox agora oferece o dobro de espaço de trabalho

O Vercel Sandbox é uma microVM Linux isolada — uma pequena máquina virtual com kernel, sistema de arquivos e rede próprios. Nela, é possível carregar um repositório, deixar um agente editar o código, instalar pacotes, executar testes, gerar uma build e retirar o resultado ao final.

Todas essas etapas usam o mesmo disco local. O checkout pode continuar ocupando espaço quando a árvore de dependências chega. Caches de build e arquivos compilados podem coexistir com arquivos temporários. Mesmo que o artefato final seja pequeno, o job pode exigir muito mais espaço por alguns instantes durante a geração.

É esse pico que muda com o lançamento. Agora, a Vercel oferece 64 GB de armazenamento de trabalho no Sandbox, em vez de 32 GB: um aumento de 32 GB e o dobro da capacidade anterior. A mudança vale para Sandboxes criados a partir de uma Vercel Managed Image, de uma imagem personalizada e da propriedade runtime, que está obsoleta.

Essa é uma capacidade interna do Sandbox, não uma nova franquia de banco de dados ou de armazenamento de objetos. A Vercel a descreve como armazenamento NVMe efêmero. Se os arquivos precisarem sobreviver ao job, a decisão sobre persistência continua sendo uma questão separada.

A decisão para o negócio: o job inteiro cabe?

A pergunta mais duradoura não é “qual é o limite de disco da Vercel?”, mas sim “este job inteiro consegue rodar em um único Sandbox, sem cortes especiais nem transferências entre etapas?”

Use um orçamento simples para o espaço de trabalho:

Pico do espaço de trabalho = repositório e checkout + dependências instaladas + artefatos de build + pico de dados temporários

Meça o ponto máximo enquanto o job estiver rodando. Não faça a estimativa com base no arquivo zip final. Extração de pacotes, compilação, fixtures de teste, binários de navegador, caches e um spill de dados podem se sobrepor por poucos minutos — mas são esses minutos que determinam se a execução termina.

Os preços e limites atuais da Vercel separam as camadas de armazenamento em linhas diferentes do orçamento:

Essa distinção muda o cálculo de custos. Dobrar o disco de trabalho não dobra a tarifa de computação. No exemplo atual da Vercel para iad1, uma execução de build e testes de 30 minutos, com 4 vCPUs e 8 GB de memória, custa cerca de $0.34 com uso total de CPU.

Um job maior ainda pode custar mais se demorar mais ou exigir mais CPU e memória. Downloads de pacotes, repositórios, artefatos e conjuntos de dados são gratuitos, enquanto os dados enviados para fora do Sandbox são cobrados.

É na persistência que arquivos extras podem gerar uma nova conta de armazenamento. Se uma execução usasse e retivesse todos os 32 GB recém-disponíveis por um mês inteiro, o cálculo pela tabela de preços seria 32 × $0.08 = $2.56 por snapshot-mês. É apenas uma ilustração, não uma cobrança automática. Uma execução não persistente que exporta o resultado e descarta o espaço de trabalho evita essa linha de custo do snapshot.

Quem pode aproveitar o espaço extra

Staff engineer com um monorepo grande

Hoje, um staff engineer talvez precise podar pacotes, remover fixtures de teste ou dividir uma build porque o repositório, o grafo de dependências e a saída da build não cabem simultaneamente abaixo do limite antigo.

Se o pico medido agora couber no sistema de arquivos de 64 GB disponível, a equipe poderá reunir checkout, instalação, testes e build novamente em um único job. O ganho é operacional: menos transferências entre etapas, menos artefatos parciais e um único job para repetir quando a build falhar.

Isso não torna automaticamente a Vercel o provedor de Sandbox ideal. Para quem ainda está escolhendo a camada de execução, a comparação mais ampla de sandboxes de código para agentes de IA aborda os trade-offs de isolamento e cobrança. Este lançamento altera apenas o limite de disco da Vercel.

Engenheiro de plataforma de agentes que repara repositórios

Um agente de programação costuma acumular dados enquanto trabalha. Ele clona o repositório, instala ferramentas, modifica arquivos, executa a suíte de testes e empacota o resultado. Se explorar várias abordagens, o agente também pode deixar caches e saídas intermediárias para trás.

Os 32 GB extras dão mais espaço para que todo esse ciclo termine em um único Sandbox. Isso pode eliminar uma nova tentativa provocada por falta de espaço em disco ou uma ferramenta personalizada de limpeza no workflow do agente. O benefício é maior quando o disco era a causa real da falha. Um job limitado por memória, CPU, política de rede ou duração da sessão não ganha nada com um sistema de arquivos maior.

Engenheiro de dados cuja transformação recorre ao disco

Um engenheiro de dados pode usar o sistema de arquivos local como área temporária enquanto uma transformação ordena, combina ou expande dados baixados. O disco maior pode manter esse trabalho temporário na máquina, sem obrigar a equipe a dividir a tarefa antes da hora ou montar um volume remoto.

A saída ainda precisa de um plano de destino. Copie para fora do Sandbox o resultado que precisa persistir, grave-o no armazenamento de objetos correto ou monte um Drive quando execuções futuras precisarem do mesmo diretório. Um disco temporário de 64 GB é útil justamente porque pode ser descartado. Tratá-lo como armazenamento permanente mistura duas tarefas e duas cobranças diferentes.

Equipes que ainda usam runtime

O lançamento de 11 de setembro inclui explicitamente os Sandboxes configurados com a propriedade runtime, que está obsoleta. O código existente deve receber o disco maior sem precisar migrar de imagem.

A plataforma continua priorizando o uso de imagens. A partir da versão 3 do Sandbox SDK, um Sandbox sem runtime nem image usa vercel/sandbox/universal:latest. As imagens gerenciadas são atualizadas todas as noites, e fixar um digest oferece um ambiente imutável quando builds reproduzíveis são importantes.

Como medir um job representativo antes de mudar o workflow

O lançamento elimina um limite. Ele não informa quanto espaço a sua imagem e o seu job realmente têm. Meça uma execução real antes de excluir etapas de limpeza ou voltar a unir builds divididas.

1. 1

   Escolha o job que comprova a decisão

   Selecione um job que tenha ficado sem espaço em disco recentemente ou que hoje seja dividido apenas para permanecer abaixo do limite antigo. Use o mesmo repositório, lockfile, comando de build e dados de entrada do fluxo de produção. Um repositório de demonstração não responde à pergunta do negócio.

2. 2

   Inicie um Sandbox novo baseado em imagem

   A CLI atual e o fluxo baseado em imagem tornam o resultado mais fácil de reproduzir. Esta sequência segue o fluxo documentado do Sandbox CLI da Vercel e desativa a persistência para que a medição não crie um snapshot automático.

   npm i -g sandbox
   sandbox login
   sandbox create --name workspace-check --image vercel/sandbox/node:24 --timeout 30m --non-persistent
   
   tar -czf app.tgz -C ./my-app .
   sandbox copy ./app.tgz workspace-check:/tmp/app.tgz
   sandbox exec workspace-check -- sh -c "mkdir -p /app && tar -xzf /tmp/app.tgz -C /app"

3. 3

   Registre cada etapa de uso do armazenamento

   Execute a verificação de disco depois do checkout, após a instalação das dependências, durante a parte mais pesada da build, se possível, e quando o artefato estiver pronto. Substitua .next e dist pelos caminhos de saída que o seu projeto realmente usa.

   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm install
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm run build
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'

   df -h / mostra quanto espaço ainda resta no Sandbox. As linhas com du indicam qual parte do espaço de trabalho o está consumindo. Verificar apenas depois da build final pode ocultar o pico.

4. 4

   Repita uma vez sem a solução de contorno antiga

   Se o ponto máximo medido permanecer dentro do espaço livre informado, repita o mesmo job sem a poda de dependências nem a transferência entre etapas da build dividida. Registre se houve sucesso, o tempo total, Active CPU, a memória provisionada, a transferência e se algum snapshot ou armazenamento em Drive foi criado. Em seguida, encerre o Sandbox.

   sandbox stop workspace-check

Até onde o ganho realmente vai

Mais disco não compra mais memória, CPU ou tempo. Uma sessão do Sandbox ainda dura 5 minutos por padrão. Sessões Hobby podem rodar por até 45 minutos, enquanto sessões Pro e Enterprise podem chegar a 24 horas.

O lançamento também não garante que qualquer carga de trabalho abaixo de 64 GB caberá sem problemas. A imagem inicial ocupa parte do sistema de arquivos, e tags de imagem flutuantes podem mudar à medida que a Vercel publica atualizações noturnas. Verifique o espaço livre real após a inicialização. Fixe o digest de uma imagem se a mesma build precisar começar sempre no mesmo ambiente.

Se um job exigir dados duráveis e compartilhados, use um Drive ou outro armazenamento persistente. Se precisar de mais espaço de trabalho do que o Sandbox informa, mantenha a divisão, transfira o grande conjunto de dados temporários para um armazenamento montado ou execute o job em outro lugar. O novo limite muda o ponto de corte, não a natureza dessas opções.

O que fazer na segunda-feira

Aja ainda esta semana se um repositório, agente ou job de dados real falhou no limite antigo de disco ou mantém código de limpeza apenas para evitá-lo. Espere se você ainda não mediu o pico: remover uma divisão que funciona com base em um palpite apenas adia a próxima falha. Nada muda se o job já fica confortavelmente abaixo da capacidade anterior ou se o gargalo real é CPU, memória, acesso à rede, duração da sessão ou armazenamento durável.

Na segunda-feira, escolha um job representativo, execute a medição acima em um Vercel Sandbox novo, baseado em imagem e com 64 GB, e tente novamente uma vez sem a antiga solução de contorno para o armazenamento. Mantenha o caminho mais simples, em um único job, somente se a execução medida terminar e a conta completa de computação e persistência ainda fizer sentido.

Para receber mais análises em linguagem simples sobre mudanças que alteram os custos e as decisões operacionais, assine a newsletter.