noticias

Vercel por dentro: por que a plataforma virou referência para aplicações web e onde custos, dependência e segurança cobram a conta

**Categoria editorial:** Software / Cloud / Desenvolvimento Web

**Palavra-chave principal:** Vercel

**Linha fina:** A Vercel transformou o deploy de aplicações modernas em poucos cliques e se tornou o habitat natural do Next.js. A mesma abstração que elimina boa parte do trabalho de infraestrutura, porém, traz custos variáveis, dependência tecnológica e uma superfície de risco que ficou mais visível nos últimos anos.

**Meta description:** Vercel simplifica deploys e escala aplicações web, mas cobra em custos, dependência e segurança. Entenda vantagens, falhas, casos reais e riscos.

**Slug:** `vercel-vantagens-riscos-custos-vulnerabilidades-nextjs`

Matéria completa

A Vercel conseguiu realizar uma pequena façanha no desenvolvimento web: transformar tarefas que antes exigiam configuração de servidor, proxy reverso, certificados HTTPS, pipeline de CI/CD, CDN, balanceamento e monitoramento em uma experiência próxima de conectar um repositório Git e apertar um botão.

É uma das razões pelas quais a plataforma se tornou especialmente associada ao Next.js, framework de código aberto mantido pela própria empresa. Mas chamar a Vercel apenas de “hospedagem para Next.js” já não descreve adequadamente o negócio. Em 2026, seu catálogo inclui distribuição global de conteúdo, funções serverless, Fluid Compute, firewall, armazenamento, observabilidade, workflows, filas, ferramentas de IA, AI Gateway e sistemas de deployment e colaboração.

A proposta é tentadora: o desenvolvedor pensa mais no produto e menos no servidor.

O problema é que o servidor não desapareceu.

Ele apenas ficou escondido.

E é justamente nessa diferença que estão tanto as melhores qualidades da Vercel quanto seus maiores riscos.

O que exatamente é a Vercel?

A empresa nasceu com outro nome.

Em 2016, a então ZEIT apresentou uma ferramenta chamada `now`, cuja ideia era permitir que um desenvolvedor colocasse uma aplicação na internet com um único comando. Em abril de 2020, a companhia anunciou a mudança de nome para Vercel e consolidou a estratégia de integrar desenvolvimento, preview e publicação em uma mesma plataforma. O Next.js tornou-se seu projeto de código aberto mais importante.

A lógica permaneceu praticamente a mesma, mas ganhou dimensões muito maiores.

Um desenvolvedor conecta um projeto hospedado, por exemplo, no GitHub. Cada alteração pode gerar automaticamente um deployment isolado. Uma pull request pode receber sua própria URL de preview. Depois da aprovação, a versão entra em produção sem que a equipe tenha de configurar manualmente boa parte da infraestrutura necessária.

Esse fluxo é uma das armas mais fortes da Vercel.

Além disso, a plataforma distribui conteúdo por sua rede, executa código de servidor por meio de funções e Fluid Compute, cuida de TLS, cache, roteamento, mitigação de DDoS, firewall e outros componentes.

Por trás dessa aparente ausência de infraestrutura, entretanto, existe muita infraestrutura.

A própria Vercel afirma utilizar primitivas da AWS e operar serviços de Compute, CDN e Firewall distribuídos por regiões da Amazon. Em um post-mortem publicado em 2025, a empresa informou que operava esses serviços em 19 regiões AWS, com presença de rede em dezenas de cidades e mais de uma centena de pontos globais.

Em outras palavras, a Vercel não acabou com a complexidade da nuvem.

Ela empacotou essa complexidade em uma interface muito melhor.

O que a Vercel faz muito bem

O primeiro grande mérito é a experiência de desenvolvimento.

Para uma equipe pequena, a diferença pode ser enorme. Criar ambientes temporários para cada alteração de código, compartilhar uma versão com designers ou clientes e retornar rapidamente para um deployment anterior elimina uma quantidade considerável de trabalho operacional.

Esse ganho não é apenas cosmético.

Em empresas nas quais desenvolvedores precisam aguardar infraestrutura, DNS, pipelines ou equipes de plataforma para colocar uma mudança no ar, reduzir esse intervalo pode significar dias de trabalho poupados durante um projeto.

A integração com o Next.js também é excepcionalmente profunda.

Recursos como rendering no servidor, Incremental Static Regeneration, cache, imagens, middleware e funções são compreendidos pela plataforma durante o build. A Vercel chama essa abordagem de infraestrutura definida pelo framework: o próprio código da aplicação ajuda a indicar quais componentes de infraestrutura precisam ser provisionados.

Isso cria uma experiência difícil de reproduzir com a mesma simplicidade em uma máquina virtual convencional.

Outro ponto forte é a capacidade de absorver picos de tráfego sem obrigar uma pequena equipe a se tornar especialista em engenharia de infraestrutura.

Para sites institucionais, portais de conteúdo, SaaS, comércio eletrônico e aplicações com uma camada web distribuída, isso pode ser extremamente valioso.

Um caso que mostra onde a Vercel funciona

Um dos exemplos mais interessantes é o da equipe de eleições do The Washington Post.

Antes da mudança, segundo um estudo de caso publicado pela própria Vercel, a camada de rendering utilizada pela equipe funcionava sobre AWS ECS e dependia de uma combinação de SQS e EC2 para coordenar atualizações. A estrutura precisava processar continuamente dados eleitorais e suportar picos de acesso durante a noite das eleições americanas.

A equipe posteriormente adotou Next.js e Vercel para as eleições legislativas de 2022.

O benefício descrito pelos engenheiros não foi simplesmente “o site ficou mais rápido”. O ganho central estava na redução da complexidade operacional e na capacidade de colocar jornalistas, editores, desenvolvedores e designers trabalhando sobre previews antes da publicação.

Esse é provavelmente o melhor argumento comercial a favor da Vercel.

Ela não vende apenas CPU e transferência de dados.

Ela vende menos tempo gasto pensando em infraestrutura.

A Weather Company mostra o outro extremo

Em junho de 2026, a Vercel divulgou outro caso de grande escala envolvendo a The Weather Company.

Segundo os números apresentados pela própria plataforma, a empresa atende cerca de 350 milhões de usuários ativos mensais e trabalha com aproximadamente 2,2 bilhões de coordenadas recalculadas a cada 15 minutos. O estudo de caso atribui à nova arquitetura uma melhoria de 80% na velocidade entre o design e a publicação de páginas.

Como se trata de material produzido pela Vercel sobre um cliente, esses números devem ser interpretados como dados fornecidos pelas empresas, e não como benchmark independente.

Ainda assim, o caso desmonta uma interpretação comum de que a Vercel seria adequada apenas para blogs, landing pages ou pequenos projetos.

Ela pode operar em escala muito maior.

A questão passa a ser outra: quanto custa essa conveniência e quanta dependência arquitetural a empresa está disposta a aceitar?

A parte ruim começa quando a aplicação cresce

O plano Hobby continua gratuito, enquanto o Pro custa atualmente US$ 20 por mês e inclui US$ 20 em créditos de uso.

O número sozinho, porém, diz pouco.

Depois das franquias, existem cobranças relacionadas a transferência de dados, solicitações na borda, CPU ativa, memória provisionada, execuções de funções, transformações de imagens, cache, armazenamento, builds, observabilidade e outros recursos. No Pro, por exemplo, a plataforma informa 1 TB mensal de Fast Data Transfer incluído e cobra a partir de US$ 0,15 por GB adicional.

Functions também deixaram de ser uma conta baseada simplesmente em “quantas funções existem”. O modelo Fluid Compute considera dimensões como CPU efetivamente utilizada, memória provisionada e número de invocações.

Tecnicamente, isso faz sentido.

Financeiramente, cria uma característica importante: prever a conta exige compreender o comportamento real da aplicação.

Um site com conteúdo altamente cacheável pode custar relativamente pouco.

Uma aplicação com grande volume de rendering dinâmico, processamento de imagens, tráfego intenso e muitas funções pode ter uma curva totalmente diferente.

É aqui que aparece uma das críticas recorrentes à Vercel: o preço inicial é simples; a economia da aplicação em escala não necessariamente é.

Quando um cliente decide ir embora

A plataforma de inteligência de fontes abertas Osintly publicou em 2025 um relato detalhando sua migração completa da Vercel para a Cloudflare.

O texto merece atenção justamente porque começa reconhecendo a qualidade da Vercel.

A equipe elogia o fluxo baseado em Git e a experiência de desenvolvimento, mas afirma que encontrou problemas de previsibilidade de custos, limitações na configuração de firewall, visibilidade insuficiente de determinados eventos de segurança e cobranças relacionadas ao crescimento do tráfego.

A Osintly também queria preservar um modelo no qual a Cloudflare permanecesse como camada de proxy, segurança e Zero Trust. A empresa acabou migrando a aplicação Next.js para Workers e outros serviços da Cloudflare.

Esse caso não prova que Cloudflare seja universalmente melhor ou mais barata.

Ele mostra algo mais interessante: a arquitetura que reduz drasticamente o trabalho de infraestrutura no começo pode tornar-se uma restrição quando a empresa passa a querer controlar cada camada dessa infraestrutura.

O lock-in que quase ninguém percebe no primeiro deployment

Next.js é código aberto.

Pode ser executado fora da Vercel.

Isso precisa ficar claro.

Mas portabilidade de código e portabilidade de arquitetura são coisas diferentes.

Uma aplicação que utiliza apenas funcionalidades relativamente padronizadas pode migrar sem drama significativo. Já outra profundamente integrada a ISR, regras específicas de cache, otimização de imagens, ambientes de preview, middleware, funções, Blob, observabilidade e outros serviços da plataforma pode exigir adaptações consideráveis.

Projetos como OpenNext existem justamente para ampliar essa portabilidade. A própria Osintly relata ter utilizado a iniciativa após a mudança para a Cloudflare.

A ironia é interessante.

Quanto melhor a Vercel fizer seu trabalho, menos o desenvolvedor precisará compreender a infraestrutura subjacente.

E quanto menos ele precisar compreender essa infraestrutura, maior pode ser o choque quando resolver sair.

Quando a nuvem da nuvem cai

Existe outro risco inerente a qualquer plataforma gerenciada: dependências em cascata.

Em 20 de outubro de 2025, uma grande interrupção na AWS atingiu também a Vercel.

Segundo o post-mortem da própria companhia, a perda da região `us-east-1` provocou dois incidentes independentes. Em determinado momento, uma falha em cascata afetou parte da infraestrutura global de cache, fazendo as falhas no fornecimento de arquivos estáticos atingirem um pico próximo de 22% do tráfego.

A situação também afetou dashboard, APIs, builds e processamento de logs.

A Vercel foi bastante explícita ao assumir responsabilidade pelo episódio, mesmo reconhecendo que o evento inicial havia ocorrido na AWS.

Essa distinção é importante.

Contratar Vercel sobre AWS não remove a AWS da cadeia de dependências.

Acrescenta uma nova camada que tenta protegê-lo da complexidade da AWS.

Na maior parte do tempo isso funciona.

Quando uma combinação improvável de falhas ultrapassa os mecanismos de redundância, porém, surge o risco clássico de dependências em cascata.

E houve problemas bem mais recentes

A página oficial de status registrou um incidente envolvendo deployments construídos entre 12 e 13 de agosto de 2026.

Em condições específicas — Next.js 16.2 ou anterior, Pages Router com internacionalização e rotas dinâmicas de API — determinados deployments podiam devolver erro 404. A Vercel informou que os projetos afetados precisavam ser novamente publicados porque os deployments anteriores não seriam corrigidos automaticamente.

É um problema muito menor do que a interrupção de 2025.

Mas é um lembrete útil: automatização reduz erro operacional do usuário, não torna a própria plataforma incapaz de introduzir regressões.

Vulnerabilidade crítica no middleware do Next.js

Segurança exige separar o framework da plataforma.

Em março de 2025, veio a público a CVE-2025-29927, uma vulnerabilidade crítica no Next.js que podia permitir o bypass de verificações de autorização quando essas verificações eram realizadas no Middleware.

Aplicações Next.js auto-hospedadas em determinadas versões estavam vulneráveis.

Curiosamente, os deployments na própria Vercel não eram afetados porque sua arquitetura separava a lógica de roteamento do processo executado pela aplicação. Cloudflare Workers e Netlify também não eram afetados pelo mesmo motivo arquitetural.

O episódio, contudo, trouxe uma segunda questão.

No post-mortem, a própria Vercel reconheceu atraso no processo de triagem inicial. O primeiro relato foi enviado em 27 de fevereiro; uma ampliação do escopo chegou em 1º de março e a confirmação interna da vulnerabilidade ocorreu posteriormente. A empresa afirmou ter revisto seus processos de divulgação e relacionamento com outros provedores.

É uma vulnerabilidade interessante justamente porque demonstra duas coisas ao mesmo tempo.

Vercel não é automaticamente vulnerável porque Next.js é vulnerável.

Mas quem controla um framework utilizado por milhões de aplicações assume uma responsabilidade de segurança que ultrapassa sua própria infraestrutura.

Depois veio uma vulnerabilidade ainda mais séria

Em dezembro de 2025, o ecossistema React enfrentou um problema de outra dimensão.

A CVE-2025-55182 atingiu React Server Components e recebeu pontuação CVSS 10.0. A falha permitia execução remota de código sem autenticação por meio da maneira como determinados payloads eram processados por endpoints de Server Functions.

Next.js estava entre os frameworks afetados pela vulnerabilidade.

Novamente, isso não significa que “a Vercel foi hackeada por causa do Next.js”.

Significa que aplicações modernas carregam uma cadeia de dependências enorme: runtime, framework, bibliotecas, infraestrutura, identidade, serviços externos e APIs.

O conceito de serverless elimina servidores da rotina do desenvolvedor.

Não elimina vulnerabilidades de software.

E em abril de 2026 a própria Vercel sofreu uma invasão

O episódio mais delicado ocorreu em abril de 2026.

A Vercel confirmou acesso não autorizado a determinados sistemas internos e informou que um subconjunto de clientes havia sido impactado.

A origem não teria sido uma vulnerabilidade explorada diretamente na infraestrutura pública da Vercel.

Segundo a investigação divulgada pela empresa e reportagens posteriores, o ataque começou após o comprometimento da Context.ai, ferramenta terceirizada de inteligência artificial utilizada por um funcionário. O acesso por OAuth ao Google Workspace abriu caminho para o invasor alcançar ambientes internos.

Algumas variáveis de ambiente de clientes que não haviam sido marcadas como sensíveis foram comprometidas.

A empresa entrou em contato com os clientes afetados e recomendou rotação imediata das credenciais. Também afirmou não ter encontrado evidências de comprometimento de pacotes npm.

Esse talvez seja o episódio mais instrutivo de toda a história recente da companhia.

O vetor não estava no CDN.

Não estava no Next.js.

Não estava no serverless.

Estava na identidade e na cadeia de confiança criada por uma ferramenta SaaS conectada a outra ferramenta SaaS.

É exatamente o tipo de risco que cresce conforme empresas concedem a agentes de IA, extensões, bots e aplicativos acesso aos seus ambientes corporativos.

Vercel é segura?

A resposta responsável não é simplesmente sim ou não.

Vercel oferece WAF, mitigação de DDoS, TLS, controle de acesso e outros mecanismos que uma pequena equipe provavelmente teria dificuldade para construir com o mesmo nível de maturidade sozinha.

Ao mesmo tempo, colocar aplicações, deployments e segredos em uma plataforma aumenta a importância daquele fornecedor dentro do modelo de ameaça da empresa.

O incidente de 2026 mostra por que variáveis realmente sensíveis devem ser classificadas como tal, chaves precisam ser rotacionáveis e permissões OAuth devem seguir o princípio do menor privilégio.

Uma organização madura também não deve tratar secrets armazenados em qualquer plataforma como permanentes.

Credencial que não pode ser rapidamente revogada já é um problema antes mesmo de existir um ataque.

O maior concorrente da Vercel talvez não seja outra nuvem

Cloudflare, Netlify, AWS, Render, Fly.io e servidores próprios podem competir com diferentes partes do que a Vercel oferece.

Mas existe uma comparação ainda mais importante.

Quanto custa um engenheiro pensando em infraestrutura?

Essa pergunta muda completamente a discussão.

Uma VPS de poucos dólares pode executar uma aplicação que custaria mais na Vercel.

Mas alguém precisa atualizar o sistema operacional, configurar proxy, certificados, containers, backups, observabilidade, pipelines, segurança, deploy sem interrupção, escalabilidade e resposta a incidentes.

Quando o custo do trabalho humano entra na equação, uma plataforma gerenciada pode ser barata mesmo cobrando várias vezes o preço bruto do servidor.

Do outro lado, empresas que já possuem engenheiros de plataforma e operam grande volume de tráfego podem descobrir que estão pagando novamente por capacidades que sua própria equipe já sabe administrar.

É por isso que “Vercel é cara” e “Vercel economiza dinheiro” podem ser afirmações verdadeiras ao mesmo tempo.

Depende de quem está pagando a conta — e de qual conta está sendo medida.

Quem deveria considerar a Vercel

A plataforma faz muito sentido para startups, pequenos times, agências, equipes de frontend, projetos Next.js e empresas cuja vantagem competitiva está no produto, e não em administrar Kubernetes, proxies ou pipelines.

Ela também é especialmente atraente quando previews frequentes e colaboração entre design, produto, conteúdo e desenvolvimento fazem parte do fluxo diário.

Para esses grupos, a produtividade pode compensar amplamente o preço da infraestrutura.

E quem deveria pensar duas vezes

Aplicações com consumo muito alto e previsível de largura de banda podem encontrar alternativas economicamente mais interessantes.

O mesmo vale para workloads longos, sistemas profundamente dependentes de processos persistentes, organizações que exigem topologias específicas de rede ou equipes que precisam controlar detalhadamente todas as camadas da infraestrutura.

Empresas submetidas a requisitos regulatórios também precisam analisar onde dados, logs, segredos e processamento serão armazenados, em vez de assumir que a simples utilização de um grande fornecedor resolve automaticamente compliance.

E existe uma recomendação válida para qualquer projeto, independentemente do tamanho:

saiba como sair antes de entrar.

Uma arquitetura saudável deve possuir algum plano de migração, ainda que ele jamais seja utilizado.

Curiosidades que ajudam a entender a Vercel

A Vercel nasceu tentando eliminar atrito de deployment antes de se transformar em uma plataforma de cloud completa.

Seu antigo nome era ZEIT e seu primeiro produto mais conhecido chamava-se `now`.

A empresa também ocupa uma posição incomum no mercado porque mantém o Next.js ao mesmo tempo em que comercializa provavelmente a infraestrutura mais integrada ao framework.

Isso cria um ciclo poderoso: melhorias no framework podem ser aproveitadas rapidamente pela plataforma, enquanto problemas observados na infraestrutura podem influenciar a evolução do framework.

Mas também concentra influência considerável sobre uma parte importante do ecossistema React.

Outra curiosidade é que a aparente simplicidade da Vercel depende de uma arquitetura bastante menos simples por baixo.

A própria companhia possui uma relação histórica com a AWS e reconhece utilizar primitivas da infraestrutura da Amazon.

O produto que promete fazer desenvolvedores esquecerem a nuvem é, em grande parte, uma maneira extremamente sofisticada de organizar a própria nuvem.

Análise da equipe

A principal qualidade da Vercel não é velocidade de CPU, quantidade de regiões ou número de funcionalidades.

É reduzir o custo cognitivo de publicar software.

Durante muito tempo, a indústria discutiu cloud computing principalmente em termos de servidores, containers, memória e processamento. A Vercel entendeu que existe outro recurso igualmente escasso dentro de uma empresa: atenção de desenvolvedor.

Seu produto transforma dinheiro de infraestrutura em tempo de engenharia.

Para equipes pequenas, essa troca é frequentemente excelente.

Para organizações grandes, a equação precisa ser refeita periodicamente.

O perigo aparece quando conveniência vira dependência sem que ninguém perceba.

Uma equipe que consegue publicar 20 versões por dia graças à Vercel está claramente recebendo valor. Uma equipe que não sabe mais explicar como sua aplicação funciona fora da Vercel adquiriu também uma dívida arquitetural.

As duas coisas podem acontecer simultaneamente.

A Vercel vale a pena?

Para muitos projetos, sim.

Provavelmente continua sendo uma das maneiras mais eficientes de colocar uma aplicação Next.js em produção sem construir uma pequena equipe de DevOps ao redor dela.

Sua experiência de deployment é difícil de criticar, a integração com Git e previews é excelente e a plataforma consegue atender desde projetos individuais até operações de grande escala.

Mas tratá-la como solução automática para qualquer aplicação seria um erro.

Custos precisam ser monitorados.

Segredos precisam ser tratados como descartáveis e rotacionáveis.

Dependências precisam ser conhecidas.

Atualizações de Next.js e React precisam entrar na rotina de segurança.

E aplicações críticas deveriam possuir estratégia de contingência independentemente de qual fornecedor esteja por trás delas.

A grande lição da Vercel é quase paradoxal.

A empresa conseguiu esconder uma parcela enorme da complexidade da web moderna.

Mas quanto mais importante a aplicação se torna, mais necessário é lembrar que toda aquela complexidade continua existindo em algum lugar.

E alguém continua responsável por ela.

👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis