Como Publicar seu App Feito com IA: Deploy na Vercel Passo a Passo [2026]

Seu app funciona no preview do Lovable, no chat do v0 ou no localhost da sua máquina, e agora ele precisa existir num endereço que outra pessoa consiga abrir. O deploy na Vercel é o passo que mais trava quem criou o produto conversando com uma IA, porque é o momento em que o código sai do ambiente controlado da ferramenta e encontra um servidor de verdade, com variáveis de ambiente, sistema de arquivos case-sensitive, versão de Node fixa e um build que falha por vírgula fora do lugar.

Na Marfin publicamos dezenas de projetos assim, do MVP interno de duas telas ao produto que atende cliente pagante. O padrão se repete: a parte criativa demora horas, e a publicação trava por três dias em erros que ninguém explicou. Chave de API que ficou hardcoded no componente, import com letra maiúscula errada, dependência instalada no chat mas nunca escrita no package.json, window sendo chamado num server component.

Este guia cobre o caminho inteiro. Preparação do repositório, deploy na Vercel passo a passo pelo painel e pelo terminal, configuração de variáveis de ambiente, domínio próprio, o que mudou na infraestrutura da plataforma em 2026, os erros de build mais comuns em código gerado por IA e como resolver cada um deles com o próprio assistente. Também tem preços atualizados e dez dicas práticas no final.

Link para esta seçãoO que muda quando o código foi escrito por IA

Código gerado por assistente tem um perfil de erro diferente do código escrito à mão. Ele costuma estar sintaticamente correto e logicamente coerente, e falha nas bordas: no que depende do ambiente, do sistema operacional, da versão do runtime e de segredos que a IA nunca viu.

O caso mais comum que enfrentamos é o de case-sensitivity. Você desenvolve no macOS, onde o sistema de arquivos ignora maiúsculas, então import Button from './components/button' funciona mesmo que o arquivo se chame Button.tsx. O build da Vercel roda em Linux, que diferencia maiúsculas de minúsculas, e o mesmo import quebra na hora. O erro aparece como "Module not found" e faz muita gente achar que a dependência sumiu.

O segundo padrão é o das dependências fantasma. Durante uma sessão longa de vibe coding, a IA sugere usar uma biblioteca, você aceita, o preview da ferramenta resolve o pacote em tempo de execução e tudo parece certo. O package.json do repositório nunca recebeu aquela linha. No build limpo da Vercel, que instala exatamente o que está declarado, o import não encontra nada.

O terceiro é o dos segredos. Assistentes escrevem código funcional primeiro e pensam em configuração depois. É comum encontrar a chave da OpenAI escrita direto no arquivo, ou uma variável marcada com NEXT_PUBLIC_ porque assim ela "funcionava no front". Esse prefixo injeta o valor no bundle do navegador, o que significa que qualquer visitante consegue ler sua chave abrindo o inspetor. Revisar isso antes de publicar economiza uma fatura desagradável.

Nada disso é motivo para desconfiar da IA. São efeitos previsíveis de um ambiente de preview que esconde a infraestrutura. Saber onde olhar transforma três dias de tentativa e erro em vinte minutos de checklist.

Link para esta seçãoAntes do deploy: o checklist que evita a maioria dos erros

O build local é o filtro mais barato que existe. Antes de conectar qualquer coisa à Vercel, clone o repositório numa pasta limpa, rode npm install e depois npm run build. Sem o node_modules antigo, sem cache, sem o servidor de desenvolvimento rodando. Se o build passa nessa pasta limpa, a chance de passar na Vercel é alta. Se falha, você tem o erro na sua frente, com stack trace completo, sem esperar fila de build remoto.

Confira também a versão do Node. A Vercel usa Node.js 24 LTS como padrão em 2026, e a versão 18 está descontinuada. Se seu projeto foi gerado com base em exemplos antigos, declare a versão que você quer no campo engines do package.json ou nas configurações do projeto, para que o ambiente local e o remoto sejam o mesmo.

Depois disso, faça uma varredura de segredos. Peça ao assistente algo direto: "liste todos os pontos deste projeto onde uma chave, token ou URL de serviço aparece escrita no código, e diga quais deveriam virar variável de ambiente do servidor". O Claude Code faz essa varredura no repositório inteiro em segundos, porque lê o projeto todo em vez de um arquivo por vez, e é por isso que ele é a ferramenta que mais usamos aqui. O resultado costuma ser uma lista curta e constrangedora.

Por último, verifique o .gitignore. Ele precisa conter .env, .env.local e node_modules. Arquivo de ambiente commitado num repositório público é uma das formas mais rápidas de ter uma chave vazada e usada por terceiros em poucas horas, porque existem bots que varrem o GitHub justamente atrás disso.

Link para esta seçãoDeploy na Vercel passo a passo: do repositório ao domínio

Com o build limpo, o processo é curto. Ele tem cinco etapas e leva menos de quinze minutos na primeira vez.

Link para esta seçãoPasso 1: leve o código para o GitHub

Se você criou o app no Lovable, ative o GitHub sync no painel do projeto. A sincronização é bidirecional, então o que você editar no repositório volta pra ferramenta e vice-versa. No v0 da Vercel, o projeto já nasce integrado. No Bolt.new, use a exportação para GitHub. Se o app nasceu no seu terminal, git init, git add ., git commit e git remote add origin resolvem.

Repositório privado funciona normalmente e é o padrão que recomendamos para qualquer coisa com lógica de negócio dentro.

Link para esta seçãoPasso 2: importe o projeto na Vercel

No painel da Vercel, escolha "Add New Project" e autorize o acesso ao GitHub. Selecione o repositório e a plataforma detecta o framework sozinha, seja Next.js, Vite, Astro, SvelteKit, Nuxt ou um backend em Express, FastAPI, NestJS ou Hono. A Vercel deixou de ser apenas hospedagem de front há tempos e roda backend completo sem configuração extra, o que importa se seu app gerado por IA tem rotas de API dentro dele.

Deixe as configurações de build no automático na primeira tentativa. Comando customizado só entra quando o padrão falha por um motivo que você já identificou.

Link para esta seçãoPasso 3: configure as variáveis de ambiente

Esta é a etapa que decide se o deploy na Vercel vai passar ou falhar. Abra a aba de Environment Variables e cadastre cada chave que seu .env.local tem. A Vercel separa por ambiente: Production, Preview e Development. Cadastre nos três se o valor for o mesmo, ou use chaves de teste em Preview quando o serviço oferecer.

Vale reforçar a regra de nomenclatura: qualquer variável com prefixo NEXT_PUBLIC_ é embutida no JavaScript entregue ao navegador. A URL pública do Supabase e a chave anônima podem ficar ali. A service_role do Supabase, a chave da OpenAI, tokens de pagamento e secrets de webhook nunca. Essas ficam sem prefixo, acessíveis somente no servidor.

Pelo terminal, o comando vercel env pull .env.local traz as variáveis já cadastradas pro seu ambiente local, o que mantém as duas pontas iguais sem copiar e colar valor a valor.

Link para esta seçãoPasso 4: rode o build e leia o log

Clique em Deploy. O log aparece em tempo real. Quando falha, a mensagem relevante quase nunca está na última linha: ela costuma estar no meio, na primeira ocorrência de "Error" ou "Failed to compile". Copie o bloco inteiro, do início do erro até o fim, e cole no seu assistente pedindo diagnóstico e correção.

Deploys de branches que não são a principal viram preview automáticos, cada um com sua própria URL. Isso é o que torna a plataforma agradável de usar em equipe: você manda o link do preview pra alguém revisar antes de qualquer coisa chegar em produção.

Link para esta seçãoPasso 5: conecte um domínio

Na aba Domains, adicione o domínio que você comprou. A Vercel mostra os registros DNS necessários, geralmente um registro A apontando pro IP dela e um CNAME para o subdomínio www. Se seu domínio está no Registro.br, na GoDaddy ou na Cloudflare, o painel de DNS de cada uma aceita esses valores. O certificado SSL é emitido sozinho, sem custo, e costuma ficar ativo em poucos minutos. Propagação de DNS pode levar até algumas horas, então não conclua que deu errado nos primeiros dez minutos.

Link para esta seçãoPublicando direto do Lovable, do v0 e do Bolt

Cada ferramenta de criação tem seu próprio botão de publicar, e em alguns casos ele basta. Vale entender o que cada caminho entrega.

O Lovable publica com um clique num subdomínio próprio e permite conectar domínio customizado nos planos pagos. Para um MVP que você quer validar rápido, isso resolve. Nosso tutorial de Lovable cobre o fluxo completo, incluindo a integração nativa com Supabase, que é o que dá banco de dados e autenticação ao projeto sem escrever backend. Quando o app cresce e passa a precisar de rotas de API próprias, cron jobs ou controle fino de cache, o caminho via GitHub e Vercel dá mais espaço.

O v0 da Vercel publica na própria Vercel por construção, o que faz dele a rota mais curta quando o objetivo é uma interface em React ou Next.js. Ele é excelente gerando componentes e telas, e menos indicado como fábrica de aplicação inteira. Vale ler o tutorial completo do v0 antes de decidir se ele é a base do projeto ou uma peça dele.

O Bolt.new é uma opção válida no mesmo grupo, com exportação pro GitHub e deploy próprio. Se você já está no ecossistema dele, funciona. Comparamos os três lado a lado em Lovable vs Bolt.new vs v0, com testes e preços, e a conclusão prática é que a escolha depende mais do tipo de app do que de qualquer ranking geral.

Independente da ferramenta, a recomendação é a mesma: assim que o projeto passa de experimento para algo que outra pessoa usa, coloque o código num repositório seu e faça o deploy na Vercel a partir dele. Você deixa de depender do botão de uma plataforma e passa a ter histórico, rollback e previews.

Link para esta seçãoConfiguração moderna: vercel.ts no lugar do vercel.json

Muito tutorial ainda mostra um vercel.json cheio de chaves. A forma recomendada em 2026 é o vercel.ts, um arquivo TypeScript tipado que substitui o JSON e aceita lógica dinâmica e leitura de variáveis de ambiente. Instale o pacote @vercel/config e exporte uma constante config tipada como VercelConfig.

Dentro dele você declara comando de build, framework, redirects, rewrites, headers de cache e cron jobs. Um redirect permanente de uma rota antiga pra nova vira uma linha com routes.redirect. Um header de cache de uma semana pra pasta de estáticos vira uma linha com routes.cacheControl. Um cron que chama /api/limpeza toda meia-noite vira uma entrada no array crons. A vantagem sobre o JSON é o autocomplete e o erro de tipo aparecendo no editor em vez de no build remoto.

Se seu app já tem um vercel.json gerado por IA, peça a migração ao assistente. É uma conversão mecânica e o Cursor AI, que é a IDE que usamos no dia a dia para building, faz isso lendo o arquivo atual e escrevendo o equivalente tipado sem drama.

Link para esta seçãoFluid Compute e o que mudou na infraestrutura

Aqui mora a maior parte da desinformação que circula, inclusive dentro dos próprios assistentes de IA, que foram treinados em documentação antiga. Vale corrigir os pontos que mais atrapalham.

Edge Functions deixaram de ser a recomendação. O padrão agora é o Fluid Compute, que roda nas mesmas regiões, custa o mesmo e oferece Node.js completo em vez do runtime limitado. Se seu código gerado por IA veio com export const runtime = 'edge' no topo de uma rota, remova. Middleware e Edge Functions rodam sobre Vercel Functions por baixo dos panos, e o Fluid reaproveita instâncias entre requisições concorrentes, o que reduz cold start de forma perceptível.

Streaming não depende de Edge. Respostas em ReadableStream, Server-Sent Events e streaming de tokens de LLM funcionam no runtime Node.js padrão sem configuração nenhuma. Essa confusão faz gente migrar rota de chat pra Edge sem necessidade e depois brigar com APIs de Node que sumiram.

Os limites também subiram. O timeout padrão de execução é de 300 segundos em todos os planos. O tamanho de pacote de uma função chega a 5 GB, o que libera bibliotecas pesadas de Python, automação de browser com Playwright e processamento de imagem. O corpo de requisição aceita até 100 MB, então upload de arquivo pode ir direto pra uma função. E funções suportam WebSockets, o que remove a necessidade de um serviço externo de tempo real para chat ou colaboração.

Duas ausências importam para quem segue tutorial antigo: Vercel Postgres e Vercel KV não são mais oferecidos como produtos próprios. Banco de dados agora vem pelo Marketplace, com provedores integrados ao painel e às variáveis de ambiente do projeto.

Link para esta seçãoBanco de dados, autenticação e o resto do backend

Para app criado com IA, o Supabase continua sendo nosso padrão. Ele entrega PostgreSQL gerenciado, autenticação, storage, edge functions e realtime, e a integração com as ferramentas de criação é nativa em várias delas. O plano Free cobre validação, o Pro custa US$ 25 por mês, o Team fica em US$ 599 e existe Enterprise sob consulta.

Um cuidado específico: Row Level Security. Quando a IA cria as tabelas pra você, ela costuma deixar as políticas permissivas ou desligadas, porque assim o app funciona no primeiro teste. Isso significa que qualquer pessoa com a chave anônima, que está no bundle do navegador e é pública por design, consegue ler e escrever na sua base. Antes de publicar, revise cada tabela e escreva políticas que amarrem o acesso ao usuário autenticado. Peça ao assistente para listar as tabelas sem RLS ativa e propor as políticas, revisando uma a uma antes de aplicar.

Se seu app é um produto de verdade e não um experimento, também vale pensar cedo em métricas e cobrança. Publicar é o começo do trabalho, e nosso guia sobre o que é SaaS cobre o que vem depois do primeiro deploy.

Link para esta seçãoErros de build mais comuns e como resolvê-los

"Module not found" com o arquivo claramente presente é quase sempre case-sensitivity. Compare letra por letra o nome do arquivo com o do import. Renomear no Git às vezes exige git mv explícito, porque o macOS não registra a mudança de maiúscula sozinho.

"Cannot find module" apontando pra uma biblioteca é dependência ausente no package.json. Instale localmente com npm install nome-do-pacote, confirme que a linha apareceu no arquivo e commite junto com o package-lock.json.

Erros de TypeScript que não apareciam no desenvolvimento acontecem porque o servidor de dev é tolerante e o build não é. Corrija os tipos de verdade em vez de desligar a checagem, porque tipo errado em código gerado costuma indicar uma suposição errada sobre a forma dos dados.

"ReferenceError: window is not defined" significa que uma API de navegador está sendo chamada durante a renderização no servidor. A correção é mover o acesso pra dentro de um useEffect ou marcar o componente como client component.

Variável de ambiente undefined em produção geralmente é a mesma variável cadastrada só no ambiente Preview, ou um nome com diferença de grafia entre o .env.local e o painel. Vale conferir também se o deploy aconteceu depois do cadastro da variável, porque valores novos só entram no build seguinte.

Timeout em rota de API que chama modelo de linguagem costuma ser falta de streaming. Devolver a resposta em stream mantém a conexão viva e melhora a percepção de velocidade. Se você está montando qualquer coisa com modelos, vale conhecer também as melhores IDEs com IA em 2026, porque a diferença entre depurar isso com autocomplete e depurar com um agente que lê o log inteiro é grande.

Em todos esses casos, o fluxo que funciona é copiar o bloco de erro do log, colar no assistente com o contexto do framework e pedir a correção mínima. Evite aceitar refatorações grandes durante um debug de deploy, porque elas trocam um erro conhecido por três desconhecidos.

Link para esta seçãoPreços e planos

O plano Hobby é gratuito e cobre projetos pessoais, portfólios e MVPs em validação, com deploys ilimitados, HTTPS automático, previews por branch e domínio customizado. A restrição relevante é o uso não comercial, então um SaaS que já cobra do cliente precisa migrar.

O plano Pro custa US$ 20 por usuário por mês e inclui um valor de uso embutido, com cobrança adicional conforme consumo. Ele libera uso comercial, mais colaboradores, analytics, proteção de senha em previews, limites maiores e suporte por e-mail. Para a maior parte dos produtos pequenos e médios que acompanhamos, esse é o plano onde a conta fecha.

O Enterprise é sob consulta e faz sentido quando entram SLA formal, SSO, isolamento, suporte dedicado e volume alto.

Vale entender como a cobrança de funções funciona hoje, porque ela mudou. O modelo é de Active CPU, que cobra tempo de CPU realmente ativo, memória provisionada e número de invocações, em vez do antigo GB-segundo de tempo de parede. Na prática isso barateia bastante rotas que passam a maior parte do tempo esperando resposta de uma API externa, que é exatamente o perfil de qualquer app que conversa com um modelo de linguagem.

Bandwidth, execução de funções, transformações de imagem e builds contam no consumo. O painel de Usage mostra tudo separado, e vale visitá-lo na primeira semana pós-lançamento para descobrir qual recurso é o seu gargalo de custo antes que ele vire surpresa.

Link para esta seção10 dicas para um deploy na Vercel sem dor de cabeça

1. Rode o build local numa pasta limpa antes de tudo. Clone o repositório em outro diretório, instale do zero e execute npm run build. A maioria dos erros de deploy aparece aí, de graça e com feedback imediato.

2. Trate a branch principal como produção. Trabalhe em branches secundárias e use os previews automáticos para revisar. Isso dá rollback trivial e evita quebrar o app que alguém está usando naquele momento.

3. Cadastre variáveis de ambiente antes do primeiro deploy. Build que roda sem as chaves gera um resultado quebrado que você vai passar meia hora tentando entender. Cadastre primeiro, publique depois.

4. Audite todo uso de NEXT_PUBLIC_. Cada variável com esse prefixo vira texto legível no navegador. Se o valor é um segredo, ele não pode carregar esse prefixo, ponto.

5. Ative e revise RLS no Supabase antes de divulgar o link. Base aberta com chave anônima pública é o incidente de segurança mais comum em apps criados com assistente de IA.

6. Fixe a versão do Node. Declare no engines do package.json para que sua máquina e o build remoto usem o mesmo runtime. Node 24 LTS é o padrão atual da plataforma.

7. Remova runtime = 'edge' de rotas herdadas. O Fluid Compute é o padrão, roda Node completo, custa o mesmo e faz streaming sem configuração extra.

8. Migre a configuração para vercel.ts. Você ganha tipagem, autocomplete e erros detectados no editor, além de poder usar lógica e variáveis de ambiente na própria configuração.

9. Use vercel env pull em vez de copiar valores à mão. Um comando sincroniza o ambiente local com o que está cadastrado no projeto e elimina a classe inteira de bugs por variável divergente.

10. Olhe o painel de Usage na primeira semana. Descobrir cedo qual recurso puxa o custo evita que a conta do mês seguinte seja a sua primeira notícia sobre o assunto.

Publicar é a parte do processo que separa o protótipo bonito do produto que existe. Depois que o primeiro deploy na Vercel passa, o resto vira rotina: você faz push, o preview sobe, você revisa e promove. O ciclo inteiro dura minutos, e é isso que permite iterar num app criado com IA na mesma velocidade em que ele foi criado.

Se você ainda está montando o produto e o deploy é o próximo passo, vale olhar como as peças se encaixam antes: quais ferramentas geram qual tipo de app, onde entra o banco de dados e quando faz sentido sair do no-code para código próprio. É a diferença entre publicar algo que aguenta o primeiro lote de usuários e publicar algo que você vai reescrever em duas semanas.

Leia também:

TL;DR