Olha só, o prazo tá chegando
Se o seu projeto na Vercel ainda tá travado no Node.js 20, anota aí no calendário: 1º de outubro de 2026. Depois dessa data, o Node.js 20 é desabilitado nas Project Settings e qualquer deploy novo vai dar erro.
A boa notícia? Deploys existentes não são afetados. As Serverless Functions que já estão no ar continuam respondendo normalmente. O problema só aparece quando você faz um deploy novo — ou seja, toda terça-feira, né? 😅
E isso não é papo só da Vercel. O Node.js 20 chegou ao end-of-life oficial em 30 de abril de 2026, sem mais patches de segurança upstream. A Vercel só tá aplicando o que o cronograma do Node já decidiu. Se você roda Node 20 em qualquer lugar — Lambda, Cloud Run, EC2 — tá no mesmo barco. Vale a pena fazer uma auditoria geral, não só do lado Vercel.

Passo 1: Descobre quais projetos tão na mira
Antes de sair atualizando tudo no desespero, faz uma lista. A Vercel liberou uma flag na CLI pra isso:
# Instala a Vercel CLI mais recente globalmente
npm i -g vercel@latest
# Lista todos os projetos que ainda usam uma versão deprecada do Node.js
vercel project ls --update-required
Esse comando imprime cada projeto onde a versão do Node.js tá fora de suporte. Roda uma vez, joga numa planilha e pronto — você tem seu backlog de migração.
Passo 2: Atualiza o runtime
Você tem dois caminhos limpos:
Opção A — Project Settings UI: Vai em Settings → General → Node.js Version e troca pra 24.x.
Opção B — campo engines no package.json (recomendado):
{
"engines": {
"node": "24.x"
}
}
O campo engines tem prioridade sobre as Project Settings no próximo deploy — ou seja, a versão fica versionada no git. Chega de arqueologia do tipo "quem mudou o runtime no dashboard?"
Passo 3: Não esquece dos pins escondidos
O package.json não é o único lugar onde o Node 20 pode estar escondido. Dá um grep nesses caras antes de dar por encerrado:
.nvmrc.node-version- Configs de CI (
.github/workflows/*.yml, CircleCI, GitLab CI) - Dockerfiles locais
Depois troca o runtime local, apaga o node_modules, reinstala e roda o build completo + testes. O Node 24 vem com V8 mais novo, npm atualizado e algumas breaking changes em APIs deprecadas — daquelas que só aparecem quando você roda o teste de verdade.

A saída de emergência: deploy via container
Às vezes você realmente não consegue atualizar antes do prazo. Dependência legada, módulo nativo que não compila no Node 24, contrato com cliente que congela a stack. A resposta da Vercel é: manda como container image.
Coloca um Dockerfile.vercel na raiz do projeto:
# Fixa o Node.js 20 como imagem base
FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm ci
# Seu servidor precisa escutar na $PORT
CMD ["node", "server.js"]
Com esse arquivo no lugar, a Vercel builda e deploya a imagem em cada commit. A versão do Node.js nas Project Settings não se aplica a containers, então a depreciação não bloqueia esses deploys.
Mas seja honesto com o trade-off: agora você é dono da versão do Node.js e de cada patch de segurança upstream. O Node 20 tá em EOL — ou seja, zero correções de CVE. Container compra tempo, não segurança.
Fica de olho nisso
- Drift silencioso de versão: o
enginesdopackage.jsonsobrescreve o dashboard. Se você setou 24 na UI mas oenginesdiz 20, você ainda tá no 20. Confere comprocess.versionnuma linha de log depois do deploy. - Preview vs. Production: deploys de preview usam a mesma config de runtime. Testa a atualização numa branch de preview antes de mergear na
main. - Dependências nativas:
sharp,bcrypt,better-sqlite3— qualquer coisa com binário compilado precisa rebuild no Node 24. Mudança de ABI vai te morder. - Sem rollback pro 20 depois de 1º de outubro: uma vez que a versão é desabilitada, não dá pra voltar atrás. Se o container é sua rede de segurança, deploya ele antes do prazo.

Resumindo a ópera
O EOL do Node.js 20 nunca foi decisão da Vercel — é o cronograma upstream do Node alcançando o seu package.json. A migração em si é trabalho de 15 minutos pra maioria dos projetos: bump no engines, atualiza .nvmrc, reinstala, testa, deploya. Os projetos que sofrem são os com módulos nativos ou stacks congeladas — e esses precisam começar a planejar agora, não em 30 de setembro.
Próximos passos recomendados:
- Roda
vercel project ls --update-requiredhoje e triagem a lista. - Atualiza um projeto de baixo risco de ponta a ponta como template, depois faz o resto em lote.
- Se tá travado no Node 20, sobe o fallback de container cedo e marca uma data real pra sair dele.
Bora ler mais
- Pra times que estão formalizando a camada de plataforma, o case de platform engineering do Santander mostra como "horas em vez de 90 dias" de provisionamento funciona na prática em escala — a mesma disciplina vale pra upgrades de runtime.
- Se você tá auditando qualidade de UI junto com o runtime, esse guia de acessibilidade com CSS contrast-color() é um complemento sólido.