Ajuda · Sites feitos com IA
Funciona no meu computador, mas não no ar
Quase sempre a diferença está no ambiente, não no código: versão do Node diferente, variável de ambiente que só existe no seu computador, nome de arquivo com maiúscula que o servidor diferencia, dependência que não está no package.json ou limite da hospedagem. O registro do build mostra qual é; procure a primeira linha de erro, não a última.
Revisado em
As causas mais comuns
Versão do Node: o seu computador roda uma versão e a hospedagem outra. Fixe a versão no package.json (campo engines) ou num arquivo .nvmrc e configure a mesma na hospedagem.
Variáveis de ambiente: o arquivo .env do seu computador não vai para a hospedagem. Cada variável precisa ser cadastrada no painel dela, com o mesmo nome.
Maiúsculas e minúsculas: Windows e Mac tratam Header.tsx e header.tsx como o mesmo arquivo; o servidor Linux, não. Um import com a letra errada passa no seu computador e quebra no ar.
Dependências: um pacote instalado à mão, fora do package.json, ou um arquivo de lock desatualizado. Rode npm ci numa pasta limpa para reproduzir o que a hospedagem faz.
Quando o problema é a hospedagem
Algumas hospedagens limitam memória, número de processos ou rodam um sistema mais antigo do que as ferramentas de build esperam. Aconteceu com o nosso próprio site: o build abria processos demais para o limite do servidor, e o compilador principal do Next não rodava no sistema antigo da hospedagem. A solução foi ajustar a configuração do build e do compilador, sem trocar de hospedagem.
O sinal desse tipo de problema é um erro que fala de memória, de processos, de bibliotecas do sistema (como glibc) ou de um binário que não carrega.
Como ler o registro do build
Role até a primeira linha com “Error” ou “error”. As linhas seguintes costumam ser consequência. Copie essa linha e as três de cima, e procure o nome do arquivo e a mensagem. Se for confuso, cole o trecho para uma IA junto com o package.json: ela costuma acertar a causa quando recebe o contexto inteiro.
Para não acontecer de novo
Versão do Node fixa, variáveis listadas num arquivo de exemplo (.env.example, sem os valores), build rodado numa pasta limpa antes de publicar e publicação automática a partir do repositório, para que o que vai ao ar seja sempre o que está versionado.
Quando chamar alguém
Nem sempre precisa. Quando precisa, é isto.
Se o erro continua depois dessas verificações, ou se a mensagem fala de memória, processos ou bibliotecas do sistema, a gente lê o registro, reproduz o problema e ajusta a configuração para a sua hospedagem.
Serviço relacionado
Projetos feitos com IA→Revisão, publicação no seu domínio e manutenção.
Perguntas frequentes
Preciso trocar de hospedagem?
Nem sempre. Muitas vezes dá para ajustar a configuração do build ao limite da hospedagem. Trocar é a última opção, não a primeira.
Por que funcionava ontem e hoje não?
Uma dependência atualizou sozinha, a hospedagem mudou a versão do Node ou alguém mexeu numa variável. O arquivo de lock e a versão fixa evitam a maior parte disso.
A IA que criou o projeto consegue resolver?
Muitas vezes, sim, se você mandar o registro do build inteiro e o package.json. Sem o registro, ela chuta.
Continuar por aqui
Você fala com quem faz
O build não passa?
Você fala direto com o Gabriel, pelo WhatsApp. Mande o que aconteceu e o endereço do site, se houver.