- Um texto que aborda os problemas de abertura e governança do Next.js: ausência de adaptadores, falta de suporte serverless oficial, caminhos de código exclusivos para a Vercel e a postura da Vercel na resposta a incidentes de segurança
- A escolha da stack tecnológica é uma decisão importante que afeta no longo prazo a velocidade de desenvolvimento do projeto, a qualidade e a composição da equipe
- Softwares de código aberto dão aos usuários a liberdade de estender e modificar o código, além da vantagem de evitar dependência de fornecedor
- O Next.js é oferecido como open source, mas está intimamente ligado à infraestrutura da Vercel, que o criou
- Não há problema em uma empresa lucrar com o open source que criou, mas, para ser um modelo sustentável, a fronteira entre o open source e a empresa precisa ser clara
Contexto e conflito de interesses do autor
- O autor trabalha na Netlify há mais de 4 anos, e a Netlify concorre com a Vercel
- Ao construir diretamente na Netlify a infraestrutura e o tooling para oferecer suporte a todos os recursos do Next.js, o autor passou a ter um entendimento profundo da estrutura interna do Next.js
- Durante muito tempo evitou levantar essas questões publicamente, mas decidiu escrever este texto ao concluir que a forma como a Vercel lidou recentemente com um problema de segurança prejudicou a comunidade
# Problemas de abertura e governança do Next.js
Fato #1: ausência de adaptadores
- A maioria dos frameworks modernos pode ser configurada com flexibilidade por meio de adaptadores, dependendo do destino de deploy
- O Next.js não oferece suporte oficial a adaptadores, e o formato de saída é uma estrutura proprietária e não pública usada apenas na Vercel
- A Vercel criou a Build Output API, mas o Next.js ainda não a suporta
- Como resultado, provedores fora da Vercel precisam construir com base em APIs não documentadas, ficando vulneráveis a mudanças inesperadas
- Cloudflare e Netlify estão colaborando no desenvolvimento de adaptadores para o Next.js por meio do OpenNext, e a Vercel também começou a participar, mas ainda não há um cronograma concreto
Fato #2: falta de suporte serverless oficial
- A forma oficial de self-hosting do Next.js é baseada em servidores de longa duração, o que dificulta implementar escalabilidade flexível e redução de custos em ambientes reais de produção
- No passado existia um modo serverless, mas ele foi removido em outubro de 2022 sem maiores explicações
- A documentação oficial do React menciona que deploy serverless é possível, mas não há documentação oficial para implementar isso na prática
- Provedores de hospedagem que desejam um ambiente serverless precisam fazer engenharia reversa no Next.js e criar sua própria implementação
Fato #3: existência de caminhos de código exclusivos para a Vercel
- O Next.js inclui caminhos de código não públicos que funcionam apenas em deploys na Vercel (por exemplo, minimal mode)
- Com esse modo, a Vercel consegue otimizações de desempenho, como executar middleware na edge
- Middleware é um recurso que permite executar lógica rapidamente no caminho antes do cache, mas esse recurso só pode ser usado pela Vercel
- A Netlify montou uma equipe dedicada de engenheiros e criou sua própria implementação para oferecer suporte a esse recurso, mas isso exige um nível de recursos impossível para provedores menores
- O fato de a Vercel ser a única plataforma que oferece oficialmente todos os recursos do Next.js contraria a filosofia open source do framework
Incidente de segurança e a resposta da Vercel
- Em 21 de março de 2025, foi divulgada uma vulnerabilidade crítica no Next.js (CVE, nota 9,1) que permitia contornar autenticação
- A vulnerabilidade consistia no fato de que, ao incluir um cabeçalho específico na requisição, era possível desativar o middleware e acessar recursos protegidos
- A falha foi reportada em 27 de fevereiro, mas a Vercel só começou a investigá-la em 14 de março
- Embora tenha distribuído um patch rapidamente após reconhecer o problema, levou 8 dias para avisar outros provedores, como a Netlify
- No post inicial do blog, havia uma descrição sugerindo que o firewall da Vercel havia protegido os clientes, mas na prática isso não era verdade
- Isso levou vários provedores e desenvolvedores a reagirem com base em informações incorretas ou a enfrentarem confusão, e ainda é possível que muitos sites continuem vulneráveis
A propriedade da Vercel sobre o Next.js e a responsabilidade com o open source
- Não há como negar que a Vercel é dona do Next.js, e monetizá-lo também é legítimo
- No entanto, por ser oferecido como open source, outros provedores também deveriam poder usá-lo em condições de igualdade, e nesse ponto a Vercel está aquém do esperado
- Redis, Grafana e WordPress também operam serviços comerciais junto com projetos open source, mantendo ainda assim abertura e interoperabilidade
Conclusão
- Independentemente do framework escolhido, essa é uma decisão do usuário, e se o Next.js for a melhor opção para resolver o problema, tudo bem continuar usando-o
- Ainda assim, é importante fazer essa escolha sabendo dos problemas estruturais e das limitações que o Next.js tem hoje
4 comentários
Opiniões do Hacker News
O autor trabalha na Netlify e, segundo ele mesmo, é um concorrente direto da Vercel. Isso faz parecer que há certa falta de objetividade aqui.
Se você comparou recentemente frameworks concorrentes como TanStack ou Remix, o conteúdo principal do texto já é algo que todo mundo conhece, em maior ou menor grau. Por enquanto, a participação do Next.js ainda é tão grande e a Vercel também não tem adotado movimentos tão explícitos, então isso ainda não veio à tona.
Alegar falta de objetividade nas informações que o texto busca transmitir só porque a pessoa trabalha em uma empresa concorrente é um ataque pessoal. O texto parece estranho mesmo se você o ler sem considerar o contexto e os interesses da pessoa autora? Eu acho que é uma informação útil.