Aplicativo gerado por IA cai após o deploy: fluxo de correção simples

O que “crasha após o deploy” normalmente significa

Quando um app construído por IA funciona localmente mas falha logo depois do deploy, a produção normalmente está atingindo um caminho que seu laptop nunca testou de fato. Localmente você tem defaults de desenvolvimento, um servidor permissivo e sessões em cache. Em produção, a plataforma é mais rigorosa e o tráfego é menos previsível.

“Crash” pode significar algumas coisas diferentes, e a escolha das palavras importa porque indica onde procurar:

• Uma página em branco ou um spinner interminável (frequentemente um erro no frontend ou uma chamada de API que falhou)
• Um erro 500 em uma tela ou em um endpoint de API específico (o app está rodando, mas uma rota falha)
• Um loop de reinício onde o serviço sobe e morre repetidamente (frequentemente configuração de startup, segredos faltando ou incompatibilidade build/runtime)
• Login que só falha após o deploy (comum em callbacks de auth, cookies ou configurações de ambiente)

Protótipos gerados por IA quebram após o deploy por razões previsíveis: variáveis de ambiente faltando ou com nomes errados, configurações de autenticação que não batem com o domínio real, passos de build que funcionam localmente mas não no servidor, e problemas de banco de dados (string de conexão errada, migrations não aplicadas ou nomes de tabela diferentes).

O objetivo normalmente não é reescrever. A maioria das falhas pós-deploy se resume a uma rota com falha e uma causa concreta, como um segredo ausente ou uma query quebrada. Se você consegue reproduzir o crash, identificar a requisição exata que o dispara e ler o log apropriado da plataforma naquele momento, a correção costuma ser pequena e segura.

Se você herdou um código gerado por IA de ferramentas como Lovable, Bolt, v0, Cursor ou Replit, uma abordagem de auditoria primeiro tende a ser a mais rápida. FixMyMess, por exemplo, começa com uma auditoria de código gratuita para apontar a falha antes de mudar qualquer coisa. A mentalidade é simples: isole primeiro, mude depois.

Triagem rápida: reduza a falha em 10 minutos

Anote o que você fez imediatamente antes de falhar. Seja específico: qual página você abriu, qual botão clicou e o que esperava que acontecesse. Depois copie o texto de erro exato (ou faça uma captura de tela). Pequenos detalhes como o nome de uma rota, código de status ou “Cannot read property…” frequentemente apontam direto para a área quebrada.

Em seguida, decida o que está realmente falhando: a página, a API ou ambos.

• Uma página em branco, o overlay de erro do React ou “Application error” sugerem uma falha no frontend.
• Uma página que carrega mas quebra ao enviar um formulário frequentemente significa que uma rota backend está retornando 500.

Se você puder abrir as DevTools, verifique a aba Network. Uma requisição em vermelho costuma ser o ponto de partida.

Capture o básico para não perseguir o deploy errado: versão/commit do app, hora do deploy e em qual ambiente você testou (produção vs staging). Ambientes “quase idênticos” frequentemente divergem por uma env var ou uma URL de banco.

Por fim, note quem é afetado. Tente os mesmos passos deslogado e logado. Se apenas usuários logados crasham, a causa costuma ser auth, cookies ou um segredo ausente em produção. Se apenas usuários novos falham, pode ser uma migration ausente ou um campo obrigatório.

Esse passo de anotação de 10 minutos economiza horas e dá a uma equipe como a FixMyMess contexto suficiente para reproduzir o crash rapidamente durante uma auditoria gratuita.

Encontre os logs certos (build vs runtime vs request)

A maneira mais rápida de parar de adivinhar é decidir qual sistema você confia primeiro. Comece pelo lugar que realmente executa seu código (sua plataforma de hosting ou serverless), depois mova-se para o banco de dados, provedor de auth e APIs terceiras.

Três tipos de logs importam, e cada um responde a perguntas diferentes.

Logs de build: o deploy compilou?

Logs de build dizem se o app foi construído e empacotado corretamente. Procure por variáveis de ambiente faltantes, instalações que falharam, erros de tipo ou um passo de build que foi silenciosamente ignorado.

Se o build falhou, logs de runtime podem estar ruidosos ou vazios porque o app nunca iniciou.

Logs de runtime: o servidor iniciou e ficou vivo?

Logs de runtime mostram o que acontece quando seu app dá boot e roda em produção. É aqui que você verá crashes como “cannot read property of undefined”, configuração ruim, segredos faltando ou um processo reiniciando repetidamente.

Mantenha o foco: filtre para uma janela de tempo estreita. Comece 1–2 minutos antes de você acionar o crash e termine 1–2 minutos depois. Você quer o primeiro erro, não a pilha de falhas subsequentes.

Logs de requisição: qual chamada dispara o crash?

Logs de request conectam uma requisição HTTP específica a um erro. Procure por códigos de status (500/502/504), o caminho da rota e qualquer request ID ou trace ID.

Ao compartilhar detalhes com outra pessoa, limite-se ao que é necessário e seguro:

• Mensagem de erro e stack trace
• Rota (por exemplo, POST /api/login)
• Request ID e timestamp
• Versão do deploy/build

Não cole dumps de ambiente, headers com tokens, cookies ou strings de conexão do banco. Esses quatro itens costumam ser suficientes para reproduzir a falha sem expor segredos.

Mapeie o crash para uma rota com falha

Um crash pós-deploy muitas vezes parece aleatório porque você só vê uma página em branco, um spinner ou um “Something went wrong”. Torne-o solucionável mapeando a ação do usuário para a requisição exata que dispara a falha.

Comece pela ação do usuário: carregar a home, clicar em “Salvar”, submeter login, abrir um dashboard. Essa ação normalmente dispara uma ou mais chamadas de rede. Encontre qual chamada falha primeiro. Falhas posteriores muitas vezes são efeitos colaterais.

Se puder, reproduza enquanto observa a aba Network. Procure a primeira requisição que retorna um status ruim (frequentemente 500, 401, 403 ou 404). Anote o endpoint, o timestamp e o request ID se a sua plataforma mostrar. Então combine esse timestamp com os logs de runtime do backend.

Se múltiplas chamadas acontecerem ao mesmo tempo, mantenha a isolamento simples:

• Recarregue e veja qual requisição falha primeiro
• Refaça o mesmo endpoint diretamente (mesmo método e payload)
• Desative temporariamente funcionalidades opcionais que disparem chamadas extras
• Compare um carregamento de página que funciona com um que quebra

Uma vez identificada a rota com falha, confirme o que o app espera. Se a UI chama GET /api/me logo após o login e isso retorna 500, o app inteiro pode parecer “fora” mesmo que só um endpoint esteja quebrado.

É aqui que um “crash após deploy” vira um problema concreto: um handler não consegue ler uma env var, uma query quebra nos dados de produção ou uma verificação de auth rejeita cookies reais. Conserte essa rota primeiro e o resto frequentemente se recupera.

Por que produção é diferente da sua máquina local

Seu app pode parecer OK no laptop e ainda assim falhar ao chegar em produção. Código gerado frequentemente supõe como será o ambiente, e produção é menos permissiva.

Configuração é a primeira diferença. Localmente você pode ter defaults e segredos em cache. Em produção, valores faltando ou vazios são comuns e podem fazer o servidor cair no startup ou na primeira requisição. Alguns cheques simples evitam muitas falhas:

• Variáveis de ambiente obrigatórias existem e não estão vazias (chaves de API, DATABASE_URL, segredos de auth)
• NODE_ENV e URLs base batem com o que o app espera
• Callbacks de auth e configurações de cookie combinam com o domínio deployado (secure cookies, sameSite)
• CORS permite a origem real do frontend, não só localhost
• Timeouts e limites de memória são razoáveis para rotas lentas

Dados são a próxima armadilha. Seu banco local geralmente tem migrations aplicadas, dados seed e tabelas já criadas. Produção pode ser um banco novo. Uma rota pode crashar porque uma coluna falta, um nome de tabela difere ou dados seed necessários nunca foram inseridos.

Caminhos de arquivo também se comportam diferente. Localmente ler ./data/config.json pode funcionar porque o arquivo existe no disco. Em muitos deployments, o filesystem é read-only, o diretório de trabalho é outro ou o arquivo não foi incluído no build output.

Um cenário comum: login funciona localmente, mas em produção dá 500 logo após o redirect OAuth. A causa costuma ser uma incompatibilidade entre a URL base deployada e o callback configurado, ou cookies sem secure=true sob HTTPS. O app só atinge esse caminho de código em produção, então o bug fica escondido até o deploy.

Se você precisa de um check rápido de sanidade, comece verificando segredos, migrations e configurações de auth. Essas são as diferenças de maior impacto entre local e produção.

Fluxo passo a passo para reproduzir e isolar o bug

O caminho mais rápido é transformar o “crash aleatório” em uma requisição repetível. Uma vez que você pode acioná‑la sob demanda, a correção geralmente fica clara.

Um fluxo que funciona quase sempre

1. Reproduza e escreva os passos exatos. Anote a URL, método (GET/POST), conta usada e o que você clicou ou enviou. Inclua o resultado esperado e o real (erro 500, página em branco, loop de redirecionamento).

2. Adicione logs mínimos ao redor da rota suspeita. Logue três momentos: início, entradas-chave e fim. Mantenha pequeno para não se afogar em output.

3. Rode a mesma requisição com um cliente simples. Se for uma página web, recarregue com DevTools aberto. Se for uma chamada de API, envie uma requisição usando uma ferramenta básica para poder repetir exatamente.

4. Reduza variáveis até quebrar consistentemente. Use um usuário, um dataset, um endpoint e uma configuração de ambiente. Desative features opcionais (webhooks, jobs background, retries automáticos) até que o crash seja fácil de disparar.

5. Confirme a menor mudança de código que para o crash. Faça uma mudança pequena, redeploy e rode a mesma requisição. Se o crash parar, continue em passos pequenos até entender o porquê.

Aqui está um exemplo de “logging mínimo” que ajuda sem vazar dados sensíveis:

console.log("/api/login start", { hasEmail: !!email });
console.log("/api/login query start");
// db call
console.log("/api/login end", { ok: true });

Duas regras: não logue senhas, tokens ou corpos completos de requisição. E se seus logs nunca mostram “start”, a requisição pode não estar atingindo a rota que você pensa (caminho errado, base URL errada, middleware bloqueando).

Se você herdou um codebase gerado por IA e não consegue um repro limpo, uma auditoria ainda pode ajudar identificando a rota com falha e o menor patch seguro.

As causas raiz mais comuns em apps gerados por IA

A maioria dos crashes pós-deploy não é misteriosa. São falhas previsíveis que aparecem sob configurações reais, HTTPS real e dados reais.

Os padrões abaixo são especialmente comuns em projetos gerados por IA:

• Mismatch na configuração de auth: callback ainda apontando para localhost, segredo de sessão ausente ou cookies com flags erradas sob HTTPS.
• Falhas de conexão com o banco: string de conexão errada, migration não aplicada (tabela/coluna ausente) ou pool esgotando sob carga causando timeouts.
• Confusão build-time vs runtime: o deploy passa, mas uma rota específica quebra porque importa algo só para server, usa uma API Node indisponível ou assume que um arquivo existe.
• Variáveis de ambiente ausentes e suposições de tipos: um valor é undefined em produção, mas o código o trata como string ou objeto (clássico: process.env.X.trim() ou JSON.parse(process.env.X)).
• Erros assíncronos não tratados: uma chamada externa falha (provedor de auth, email, pagamentos), não há try/catch e o processo lança uma rejection não tratada.

Um exemplo concreto: o login funciona localmente, mas em produção o provedor de auth redireciona para um callback antigo. O app tenta ler um cookie de sessão que nunca foi definido, a rota lança e as requisições ao /dashboard passam a retornar 500.

Erros comuns que desperdiçam horas

A maneira mais fácil de perder um dia é começar a mudar código antes de capturar a primeira falha. O primeiro erro costuma ser a pista mais limpa que você terá.

Um grande desperdício de tempo é mudar várias áreas ao mesmo tempo. Se você mexe em routing, auth e banco no mesmo commit, não consegue dizer o que resolveu o crash (ou o que introduziu um novo). Faça uma mudança pequena, redeploy e confirme a mudança exata no comportamento.

Outra armadilha é redeployar repetidamente sem salvar os detalhes originais. Copie o stack trace completo, anote o caminho da requisição que o disparou e registre o timestamp. Sem isso você acaba adivinhando, e os logs giram mais rápido do que imagina.

Evite atalhos de segurança “temporários”. Desabilitar checagens de auth, regras CORS ou validação de input pode esconder o bug real e criar novos riscos. Se relaxar uma checagem para confirmar uma teoria, documente e reverta em seguida.

Tenha cuidado com logging. Jogar corpos de requisição, tokens, cookies ou senhas nos logs pode criar uma brecha e ainda assim não ajudar no debug. Prefira um conjunto pequeno e seguro de campos:

• Request ID e nome da rota
• Código de status, tempo, mensagem de erro
• Redação por padrão para dados de usuário e segredos

Também não polir a UI enquanto o backend ainda está falhando. Um toast mais bonito não conserta uma rota que está lançando.

Entregue uma correção pequena sem reescrever o app

A vitória mais rápida costuma ser um patch pequeno no caminho exato da falha, não uma reescrita. Mire numa mudança que você consiga explicar em uma frase, e então prove que ela corrige o crash com a mesma requisição que falhava.

Comece com guard clauses onde os inputs de produção diferem: env vars ausentes, campos undefined, arrays vazios ou usuário nulo. Um bom patch valida cedo e retorna um 4xx claro, ou fornece um default seguro para evitar que o código exploda.

Receita simples de correção pequena:

• Valide inputs na borda da rota (query/body/headers) e retorne um erro útil.
• Proteja configuração ausente (por exemplo, se DATABASE_URL está vazia, retorne 500 e logue uma mensagem clara).
• Capture falhas esperadas (auth expirada, timeout de terceiro) e retorne uma resposta segura.
• Mantenha uma prova repetível (uma requisição que você pode rodar sempre do mesmo jeito).
• Adicione um fallback seguro para o usuário (uma página de erro ou mensagem, não uma tela em branco).

Mantenha a prova direcionada. Se o crash está em POST /api/login, salve um payload conhecido ruim e um conhecido bom, e rode os dois após o redeploy. Você não precisa de uma suíte grande de testes para confirmar que uma rota foi consertada.

Depois do redeploy, verifique usando os mesmos passos de reprodução. Tenha uma opção de rollback pronta (build ou config anterior) para reverter rápido se o patch introduzir um novo erro.

Checklist rápido antes de considerar consertado

Um crash que parece consertado localmente pode ainda estar quebrado depois do deploy. Faça uma verificação rápida em produção.

Comece pela repetibilidade:

• Você consegue reproduzir o crash duas vezes seguidas com os mesmos passos (mesma conta, mesmo input, mesma rota)?
• Depois do conserto, os mesmos passos conseguem ser executados duas vezes seguidas com sucesso em produção?

Em seguida, garanta que seus logs deixem pelo menos uma pista concreta: um caminho de rota, nome de função ou tipo de erro específico que aparece só durante a requisição com falha.

Então verifique configuração. Valores faltantes costumam parecer crashes aleatórios. Compare o que o app espera com o que a produção realmente tem, especialmente env vars obrigatórias como URLs de banco, segredos de auth e chaves de API.

Finalmente, faça uma varredura rápida de segurança enquanto o contexto ainda está fresco. Apps gerados às vezes logam segredos ou os empacotam ao cliente por engano. Confirme que não há segredos expostos em logs ou no código entregue ao navegador.

Se você continuar batendo em “crashes surpresa”, muitas vezes sai mais barato dar um passo atrás e fazer um diagnóstico estruturado do que continuar aplicando patches às cegas.

Exemplo: fluxo de login que crasha só em produção

Um padrão comum em apps gerados por IA é: tudo parece bem localmente, você faz o deploy e o app falha no momento em que alguém faz login. A home carrega, botões funcionam, então o primeiro passo backend real (auth) dispara um erro.

Normalmente é isso que acontece. Um usuário clica em “Log in”, é redirecionado ao provedor e retorna ao callback do seu app (algo como /auth/callback). Essa rota tenta criar uma sessão (definir cookie, gravar token ou armazenar registro de usuário). Em produção, esse passo final falha. A requisição lança e a plataforma pode reiniciar o processo se tratar o crash como fatal.

Nos logs de requisição ao redor do callback você frequentemente verá pistas como “Invalid redirect URI”, “Missing AUTH_SECRET”, “Cookie not set” ou “JWT decode failed”. A chave é ligar a falha a uma rota: o handler do callback.

Correções típicas são pequenas e específicas:

• Definir a URL de callback correta nas configurações do provedor e nas variáveis de produção.
• Ajustar opções de cookie em produção (por exemplo, cookies secure e domínio correto) em vez de defaults para local.
• Adicionar ou rotacionar o segredo usado para assinar sessões, e garantir que ele esteja definido em produção, não só em um .env local.

Para confirmar que foi consertado, verifique três coisas: o login completa e redireciona onde deve, os logs mostram um fluxo limpo 200/302 pelo callback, e o app para de entrar em loops de reinício após uma tentativa de login.

Próximos passos se os crashes continuarem

Se você consertou um crash de deploy mas novos aparecem, trate isso como um sinal. Falhas repetidas geralmente significam que faltam algumas bases: validação de input, limites claros entre rotas e acesso a dados, configuração de ambiente consistente e tratamento seguro de erros.

Procure o padrão. Se todo crash está ligado à mesma área (auth, escritas no banco, uploads de arquivo), provavelmente precisa de um pequeno refactor nessa camada. Se crashes pulam entre rotas não relacionadas, costuma apontar para problemas mais profundos como estado global compartilhado, configuração inconsistente ou acoplamento oculto entre módulos.

Mantenha um template curto de bug report para que cada novo crash leve minutos, não horas:

• O que mudou desde o último deploy bom (commit, env var, dependência)
• Passos exatos para reproduzir (incluindo tipo de conta e input de exemplo)
• Rota e método que falham (por exemplo, POST /api/login)
• Logs relevantes (com timestamp e request ID se disponível)
• Diferenças local vs produção (env vars, banco, versão do Node/runtime)

Se quiser uma correção rápida e verificada para um app gerado por IA que continua quebrando após deploy, FixMyMess (fixmymess.ai) pode diagnosticar o codebase, reparar a lógica com falha e endurecer as arestas que tipicamente causam incidentes repetidos. Começar com uma auditoria gratuita costuma ser a maneira mais rápida de identificar a rota exata com falha e a incompatibilidade apenas em produção por trás dela.