App do Replit funciona no preview, mas quebra depois de publicar? Um checklist para founders

Você testa o app no Replit, manda o link para alguém e logo ouve que o login, o salvamento ou o checkout não funciona. Antes de pedir ao Agent que reconstrua essas funcionalidades, use este checklist de deploy em produção no Replit. Uma diferença entre os dois ambientes pode explicar a falha sem exigir uma nova implementação.

Por que um app pode funcionar no preview do Replit e falhar em produção?

O preview do Replit e o app publicado são ambientes separados. O app em produção pode ter URL, configuração, dados e comportamento de execução diferentes do projeto que você está editando.

O guia de publicação do Replit explica que publicar cria um deployment de produção e que edições posteriores não o alteram até uma nova publicação. Primeiro, confirme que você está testando o release certo. Anote a URL pública, o horário da última publicação, a ação que falha e se a falha também acontece em uma sessão nova do navegador.

Não junte cinco prints sem relação entre si para pedir ao Agent que conserte o app inteiro. Escolha uma falha: por exemplo, um cliente novo recebe um erro depois de clicar em Salvar. Anote o resultado esperado, o resultado real e o horário. Isso dá a você algo específico para comparar com os logs da aplicação publicada.

O app está usando o tipo de deployment certo?

O deployment precisa suportar o tipo de programa que o seu app executa. Um conjunto de arquivos estáticos e uma aplicação full-stack têm requisitos de hospedagem diferentes.

Em outubro de 2026, a documentação de tipos de deployment do Replit distingue os deployments Autoscale, Static, Reserved VM e Scheduled. Confira o tipo de deployment nas configurações de Publishing e compare com o que a aplicação realmente precisa.

A mesma documentação informa que o Static não é compatível com apps criados com o Replit Agent, porque esses apps precisam de backend. Peça a um desenvolvedor que confirme os comandos de build e de execução se a aplicação foi customizada. Contratar uma máquina maior não vai consertar uma rota de servidor ausente nem um comando de inicialização incorreto.

Os secrets de produção necessários estão realmente disponíveis?

Verifique as credenciais e a configuração usadas pelo app publicado, incluindo os nomes e o ambiente a que se destinam. Uma chave disponível durante o desenvolvimento não prova que a integração em produção está configurada corretamente.

O guia de Secrets do Replit orienta a acessar Publishing → Adjust settings → Production app secrets. Ele também diferencia secrets sensíveis de valores de configuração não sensíveis. Revise ali as entradas necessárias, sem copiar os valores delas para um prompt de troubleshooting.

1. Peça uma lista dos nomes de variáveis necessárias, onde cada uma é lida e se é usada no build ou em runtime.
2. Confira se as entradas de produção correspondem exatamente a esses nomes e pertencem às contas certas de cada provedor.
3. Mantenha as credenciais do servidor no servidor; uma variável de frontend ou o bundle do navegador não é um cofre de secrets.
4. Publique novamente quando a plataforma ou o processo de build exigir e repita a ação original na URL pública.

O app publicado está lendo o banco de dados certo?

Identifique o banco de dados de produção antes de tratar registros ausentes em produção como uma interface quebrada. Os dados de exemplo visíveis em desenvolvimento podem não ser os dados que o app dos seus clientes lê.

O guia de bancos de dados de desenvolvimento e produção do Replit descreve ambientes separados e caminhos de configuração diferentes para a infraestrutura atual e a legada. Inspecione a seleção de produção na ferramenta Database e as configurações de publicação aplicáveis ao seu app. Não presuma que um tutorial feito para outra geração de projeto corresponde ao seu.

Pense em um app de diretório hipotético. O preview lista dez empresas, mas o site em produção não lista nenhuma. Antes de reconstruir o componente de lista, verifique se a produção tem algum registro de empresa aprovado. Uma importação de dados ou uma etapa de inicialização intencional pode ser o que está faltando. Copie apenas dados adequados para produção e proteja os registros de clientes existentes antes de qualquer importação ou alteração de schema.

Para uma gravação que falhou, colete a operação e o erro sem dados sensíveis. Peça a um desenvolvedor que diferencie uma falha de conexão de uma tabela ausente, uma constraint ou um problema de autorização. Trocar a connection string repetidamente pode esconder o problema original e, sem querer, apontar o trabalho de desenvolvimento para os dados errados.

Arquivos e callbacks externos funcionam no domínio público?

Verifique onde os arquivos enviados são armazenados e qual domínio os serviços externos chamam. Os dois podem parecer corretos no preview e, ainda assim, ser inadequados para a aplicação publicada.

Para uploads, o Replit App Storage oferece armazenamento de objetos persistente. Inspecione a implementação atual em vez de presumir que arquivos gravados em uma pasta de runtime têm a persistência e os controles de acesso de que o seu produto precisa. Teste o upload, a recuperação e a restrição de acesso a um arquivo depois de um release controlado.

Para provedores de login, webhooks de pagamento e links de e-mail, revise com cada provedor as origens permitidas, os endpoints registrados e as URLs de retorno. Eles devem apontar para o domínio publicado correto quando necessário. Teste o fluxo completo: sair do seu app, concluir a ação no provedor e voltar para uma tela útil.

Mantenha um pequeno inventário de integrações: serviço, ambiente, caminho público de callback, nome do secret e responsável. O inventário contém fatos de configuração, não valores de secrets. Ele facilita muito a revisão de futuras mudanças de domínio e de passagens de bastão.

Como validar a correção em produção?

Reproduza a ação original na URL pública e, em seguida, inspecione as evidências correspondentes em produção. Uma publicação bem-sucedida significa que o release foi concluído; não prova que todos os fluxos dos clientes funcionaram.

O guia de Monitoring do Replit explica status de requisições, tempo de resposta, uso de recursos e logs da aplicação. Use o horário da ação que falhou para restringir a investigação. Uso alto de recursos e um erro de aplicação são achados diferentes; por isso, faça o diagnóstico antes de alterar a capacidade.

1. Use uma conta nova no domínio publicado e repita exatamente a jornada que falhava.
2. Confirme que o registro ou o resultado da integração esperado existe depois de recarregar a página.
3. Verifique a requisição ou o log do servidor correspondente e, depois, teste com segurança um caso de falha próximo.
4. Repita a jornada principal em um celular e verifique se o que já funcionava continua funcionando.

E se o deployment ainda precisar de trabalho de desenvolvimento?

Se as verificações de configuração não resolverem a falha, delimite o trabalho de desenvolvimento em torno do ponto específico que está quebrado. Leve uma reprodução, as configurações de deployment, os erros sem dados sensíveis e um mapa dos serviços envolvidos.

Use o checklist de produção para MVPs feitos com IA, mais abrangente, antes de ampliar seu público, ou o guia sobre o loop de correções se prompts repetidos estiverem criando regressões. Para ajuda na revisão e no lançamento da próxima versão, agende uma conversa sobre o seu app do Replit. Podemos descobrir se você precisa de um ajuste de configuração, de uma mudança pontual no código ou de um plano de release mais amplo.