Publicando seu site Node.js

Como funciona

Um site em PHP ou WordPress é executado sob demanda: cada visita dispara o código e ele termina. Basta enviar os arquivos e o site está no ar.

Uma aplicação Node funciona de outro jeito: o seu código é o servidor. Ele precisa estar em execução o tempo todo, esperando as visitas. Por isso, além de enviar os arquivos, existe um segundo passo — colocar essa aplicação em execução — que é feito por nós, do lado do servidor.

Na prática: você envia por FTP e nos avisa; nós publicamos. Não é preciso ter acesso a terminal nem conhecer o servidor.

Antes de enviar: três requisitos

Estes três pontos são o que costuma impedir uma aplicação de subir. Vale conferir antes do primeiro envio.

1. A aplicação precisa aceitar a porta que informamos

Cada aplicação do servidor recebe uma porta interna própria. Se o seu código fixar um número, haverá conflito com outro site. Leia a porta do ambiente:

// certo — usa a porta que o servidor informa
const porta = process.env.PORT || 3000;
const host  = process.env.HOST || '127.0.0.1';
app.listen(porta, host);

// errado — porta fixa, e aberta para fora
app.listen(3000);

O host importa tanto quanto a porta: 127.0.0.1 significa que apenas o servidor web conversa com a aplicação, e é ele quem cuida do domínio, do HTTPS e do certificado.

2. Envie a versão já compilada

Se o seu projeto usa TypeScript, um empacotador ou qualquer etapa de build, rode essa etapa no seu computador e envie o resultado. O servidor não compila código.

3. Inclua o package-lock.json

É esse arquivo que garante que as bibliotecas instaladas no servidor sejam exatamente as mesmas que você testou. Sem ele, as versões podem divergir e a aplicação se comportar de forma diferente da sua máquina.

O que enviar

Onde enviar

Ao entrar no FTP, você verá duas pastas. Cada uma tem uma finalidade, e a diferença entre elas protege seus dados.

Se a sua aplicação também entrega as páginas (em vez de só a API), avise: nesse caso configuramos o servidor para direcionar tudo para ela, e o public_html fica sem uso.

Configurações e senhas

Aplicações costumam precisar de senha de banco, chaves de API e outros segredos. O caminho normal é um arquivo chamado .env dentro da pasta app/, com uma configuração por linha:

DATABASE_URL=mysql://usuario:senha@localhost:3306/banco
JWT_SECRET=uma-frase-longa-e-aleatoria
API_KEY=...

Pedindo a publicação

Depois de enviar os arquivos, nos avise. Para agilizar, mande estas informações junto — são as que precisamos para configurar:

Com isso configuramos a aplicação, instalamos as bibliotecas, criamos o banco se necessário e colocamos tudo no ar. Avisamos quando estiver pronto.

Atualizações depois

A partir da segunda vez, é mais simples — a configuração já está feita.

1. Compile a nova versão no seu computador.
2. Envie os arquivos alterados por FTP, substituindo os antigos.
3. Avise que enviou.

Reiniciamos a aplicação para que a nova versão entre em uso. Só as páginas e imagens em public_html valem imediatamente — o código em app/ continua rodando a versão anterior até o reinício.

Limites e boas práticas

• Cada aplicação tem um limite de memória. Se ela ultrapassar, é encerrada e reiniciada automaticamente — o que aparece como instabilidade. Se acontecer, avise: revisamos juntos se é vazamento de memória ou se o limite precisa aumentar.
• A aplicação reinicia sozinha se travar, e volta sozinha se o servidor for reiniciado. Não é preciso nos avisar nesses casos.
• Guarde os registros de erro pela sua aplicação, ou peça os logs do servidor quando precisar investigar algo.
• Teste antes de enviar. Não há ambiente de testes no plano de hospedagem: o que você envia vai para o ar.
• Mantenha uma cópia local de tudo que enviar. Fazemos backup do servidor, mas a versão original do seu projeto é responsabilidade sua.