Deploy Vercel com Turbo: mais velocidade só quando importa

Em 17 de setembro de 2026, a Vercel passou a permitir que o custo do Turbo seja aplicado a um único deploy Vercel, em vez de virar um compromisso para o projeto inteiro. Assim, dá para gastar mais em um build urgente e deixar o deploy seguinte voltar à máquina normalmente usada pelo projeto.

Um deploy Vercel com Turbo sem mudar a configuração do projeto

Uma máquina de build é o computador temporário que a Vercel disponibiliza ao seu código enquanto instala dependências, compila o app e prepara o deploy. O Turbo é a maior opção fixa: 30 vCPUs, 60 GB de memória e 64 GB de disco.

Antes dessa mudança, escolher uma máquina de build fixa exigia alterar uma configuração da equipe ou do projeto. Isso tornava um prazo curto pouco prático. Era preciso pagar pelo Turbo também nos builds rotineiros de preview ou trocar a configuração para a urgência e lembrar de desfazer a mudança depois.

A nova substituição vincula o Turbo a um único deploy. Ela não altera a configuração do projeto. Se o projeto costuma usar Basic, Standard ou Elastic, o deploy seguinte volta a essa seleção normal, a menos que outra substituição seja adicionada.

Esse é o ganho real. O gasto adicional com build pode acompanhar a urgência, não cada commit.

Turbo, Enhanced e Elastic estão disponíveis nos planos Pro e Enterprise. Projetos Hobby sempre usam Basic, portanto isso não funciona como um atalho de velocidade no Hobby. Também não traz benefício para um projeto que já executa todos os deploys no Turbo.

Três formas de ativar o Turbo em um único deploy

O método depende do que inicia o deploy. Os três caminhos selecionam a mesma substituição válida para uma única execução.

1. 1

   Use o marcador no commit do GitHub

   Em um deploy iniciado pela integração da Vercel com o GitHub, inclua o marcador exato, com diferenciação entre maiúsculas e minúsculas no corpo da mensagem do commit:

   git commit -m "Test this change with Turbo" \
     -m "#VERCEL_BUILD_MACHINE=TURBO"

   O marcador só vale para o deploy gerado por esse commit. No momento, ele não funciona nas integrações da Vercel com GitLab ou Bitbucket.

2. 2

   Use a Vercel CLI

   Em um projeto vinculado, execute:

   vc deploy --turbo

   Esse caminho exige a Vercel CLI 59.20.0 ou posterior. Se a flag não for reconhecida, a primeira verificação é saber se a CLI está desatualizada.

3. 3

   Defina o campo na API de deploy

   Quando um serviço interno de release criar o deploy por meio de POST /v13/deployments, defina buildMachine como turbo nessa requisição. O campo é opcional e se limita àquele deploy. Ele não reescreve as configurações do projeto.

É preciso ter permissão para atualizar a máquina de build do projeto. Há um modo de falha discreto que merece atenção: se o Turbo não estiver disponível ou a conta não tiver permissão, a Vercel usa a seleção normal de máquina do projeto em vez de interromper o deploy.

O custo é pequeno uma vez — e caro quando vira hábito

Hoje, a Vercel cobra pelo uso de build à razão de $0.0035 por minuto de CPU. Isso resulta em preços iniciais de $0.007 por minuto de build faturado no Basic, $0.014 no Standard quando há cobrança, $0.028 no Enhanced e $0.105 no Turbo.

Antes de multiplicar pela quantidade de CPUs da máquina, o relógio de cobrança arredonda cada build para cima até o próximo minuto inteiro. Por isso, um build no Turbo que leva 3 minutos e 40 segundos é cobrado como 4 minutos, ou $0.42.

Para comparar Basic e Elastic no nível do projeto, leia Como reduzir os custos de build da Vercel com máquinas Basic. A nova decisão aqui é mais específica: saber se um único prazo justifica o adicional do Turbo.

Exemplo de carga de trabalho, não um benchmark

Considere uma equipe que faça 20 deploys rotineiros e 1 deploy urgente por semana. Nas próprias medições, a mesma carga leva 7 minutos e 20 segundos no Basic e 3 minutos e 40 segundos no Turbo. Esses tempos foram inventados apenas para o cálculo. O Turbo não reduzirá todo build pela metade.

A substituição no único deploy urgente acrescenta $0.364 em relação à execução no Basic. Neste exemplo, esse adicional compra uma redução observada de 3 minutos e 40 segundos justamente no release que importa.

Manter os 20 builds rotineiros no Basic deixa o total semanal $7.28 abaixo do custo de executar os 21 no Turbo. Esse é o novo controle de orçamento em uma frase. A decisão real depende das suas próprias durações, pois o estado do cache, o uso de CPU, a pressão sobre a memória e o arredondamento podem alterar o resultado.

Para quem esse fluxo de trabalho faz sentido

Um fundador solo enviando uma correção para produção

Quem toca sozinho um SaaS conectado ao GitHub pode incluir o marcador no commit de um hotfix. O ganho não é deixar o projeto permanentemente mais rápido, mas reduzir a espera pelo release ligado a uma indisponibilidade, a uma promessa feita ao cliente ou a uma janela de lançamento — e voltar ao gasto normal no push seguinte.

Uma liderança de release em agência com prazo marcado

Uma agência pode usar vc deploy --turbo no release do cliente que já tem pessoas esperando pela revisão. Os previews rotineiros continuam na configuração usual do projeto, evitando que o custo de build cresça silenciosamente a cada revisão do cliente.

Uma pessoa de engenharia de plataforma com fluxo de aprovação

Uma equipe de plataforma pode adicionar buildMachine: "turbo" apenas a um caminho aprovado de release urgente em seu serviço de deploy. Assim, a capacidade computacional extra vira uma decisão explícita de release, que pode ser registrada, revisada e precificada, em vez de permanecer como padrão do projeto.

Os limites, sem maquiagem

Ter trinta vCPUs não significa que um build será executado 15 vezes mais rápido que no Basic, com 2 vCPUs. Alguns builds não conseguem manter todos esses núcleos ocupados. Segundo a Vercel, muitos projetos não aproveitam totalmente uma máquina Turbo — esse também é o motivo de o Elastic poder escolher uma máquina menor para o trabalho rotineiro.

O Turbo muda a máquina, não a política da fila. Se a maior parte da demora vem da espera por uma vaga de build, uma máquina maior pode atacar o problema errado. Antes de pagar por mais CPU, compare o tempo na fila com o tempo efetivamente gasto no build.

O estado do cache também pode invalidar a comparação. Colocar lado a lado um build padrão com cache aquecido e um build Turbo com cache frio não revela o efeito da máquina. Use revisões e condições de cache semelhantes e compare os minutos faturados, além do tempo total decorrido.

Faça um teste controlado

1. 1

   Registre o deploy normal

   Abra o Build Diagnostics e anote a seleção normal de máquina do projeto, a duração do build, o tempo de fila, os minutos faturados e o resultado. Escolha um deploy parecido com a carga urgente que interessa medir.

2. 2

   Substitua a máquina em um único deploy

   Use o marcador do GitHub, a flag da CLI ou o campo da API em um deploy comparável. Não mude a configuração de máquina de build da equipe nem do projeto.

3. 3

   Calcule o preço da economia observada

   Multiplique os minutos arredondados para cima do build no Turbo por $0.105. Compare esse valor com o uso faturado do deploy normal e, depois, divida os dólares adicionais pelos minutos realmente economizados.

4. 4

   Verifique o deploy seguinte

   Dispare mais um deploy normal, sem o marcador, a flag ou o campo da API. Confirme que ele usa a seleção de máquina habitual do projeto. Isso identifica uma alteração indevida na configuração e comprova que a substituição foi temporária.

O que fazer agora

• Aja nesta semana se você mantém um projeto Pro ou Enterprise com releases ocasionais guiados por prazos e quer preservar a configuração normal de máquina.
• Meça primeiro se o projeto usa Elastic. Ele talvez já atribua CPU e memória suficientes, e forçar o Turbo pode aumentar a fatura sem reduzir muito o tempo.
• Prefira uma configuração de projeto se a maioria dos deploys precisa do Turbo. Repetir uma exceção em todo commit é uma política disfarçada de flag.
• Ignore esta opção se você usa Hobby, já adota o Turbo como padrão ou se a demora vem principalmente da fila.

A ação para segunda-feira

Escolha um deploy representativo na segunda-feira. Registre o build normal, execute uma substituição pelo Turbo, calcule o adicional em relação ao tempo realmente economizado e, depois, envie um deploy normal para confirmar que o projeto voltou à configuração habitual.

Assine a newsletter para receber análises diretas sobre as mudanças de plataforma que afetam o orçamento ou o fluxo de trabalho.