Melhor forma de hospedar uma aplicação Node.js

Não existe um único lugar certo para hospedar Node.js. Um bot do Discord, uma API REST, um site em Next.js e um webhook que recebe dez chamadas por dia têm necessidades diferentes, e a escolha errada aparece como bot offline, timeout, conta alta ou fins de semana gastos atualizando servidor.

A decisão fica mais fácil quando você parte de critérios, compara as quatro formas mais comuns de hospedar Node.js e chega a uma recomendação por cenário. Se você já escolheu e quer o passo a passo, veja como hospedar uma aplicação Node.js.

Que critérios decidem onde hospedar Node.js?#

Cinco perguntas resolvem a maior parte dos casos:

1. O processo precisa ficar ligado o tempo todo? Bots com Gateway, servidores WebSocket, filas e jobs agendados dentro do app precisam de um processo contínuo. Uma API que só responde a requisições não precisa, mas também roda bem assim.
2. Há conexões persistentes? WebSocket, Server-Sent Events e conexões longas com bancos de dados pedem um processo que não seja destruído entre requisições.
3. Quem vai administrar o servidor? Atualizar o sistema, configurar firewall, renovar certificado e reiniciar o processo depois de uma queda dá trabalho, e alguém precisa fazer.
4. Como é o tráfego? Constante favorece capacidade fixa e custo previsível. Raro e em picos favorece pagar por uso.
5. Como você quer fazer o deploy? Upload de arquivo, git push, CLI, pipeline de CI. Quanto menos passos manuais, menos erros.

Some a esses critérios a memória que o app usa (veja como dimensionar RAM e CPU) e a distância até os seus usuários e o seu banco de dados.

Quais são as opções para hospedar Node.js?#

VPS#

Uma VPS é uma máquina virtual com acesso root. Você instala o Node.js, envia o código, roda um supervisor que reinicia o processo e coloca um proxy reverso (como nginx) na frente para TLS. Com PM2, por exemplo, o fluxo básico é:

npm install -g pm2
pm2 start index.js --name api
pm2 save
pm2 startup

O pm2 save grava a lista de processos e o pm2 startup gera o script que a recupera depois de um reboot (ele imprime um comando para você rodar com sudo). Mais detalhes em PM2 e reinício automático.

Prós: controle total, qualquer software, custo fixo. Contras: segurança, atualizações, cópias de segurança, logs e TLS ficam com você. Veja o que é uma VPS e quanto custa uma VPS.

Plataforma de hospedagem com containers#

Você envia o código (ZIP, Git ou CLI), define o comando de início e as variáveis de ambiente, e a plataforma roda o processo num container isolado. Não há sistema operacional para manter, e normalmente o reinício automático, os logs e o HTTPS vêm prontos.

Prós: deploy em minutos, processo sempre ligado, menos manutenção. Contras: menos controle sobre o sistema (sem root, ou com root limitado ao container), e cada plataforma tem suas regras de porta, memória e build. A diferença entre os modelos está em VPS, cloud ou plataforma de hospedagem.

Serverless#

Você entrega funções, e o provedor cria um ambiente a cada requisição ou evento. O número de ambientes acompanha a demanda, inclusive até zero. Em troca, há limites: uma função padrão do AWS Lambda roda por no máximo 15 minutos por invocação, o payload síncrono tem limite de tamanho e o estado em memória não é confiável entre chamadas. Existe ainda o cold start, o atraso da primeira chamada num ambiente novo.

Prós: sem custo com tráfego zero, ótimo para picos raros. Contras: não serve para processos contínuos nem conexões persistentes, e o código precisa ser escrito no formato de handler. Veja serverless ou container.

Orquestração (Kubernetes e afins)#

Você descreve containers, réplicas e regras de rede, e um orquestrador distribui tudo entre várias máquinas. É a escolha de equipes com muitos serviços e gente dedicada a operar a infraestrutura. Para um app ou um bot, é complexidade sem retorno.

Como as opções se comparam?#

Qual escolher para cada tipo de projeto?#

• Bot do Discord, Telegram (long polling) ou WhatsApp: container sempre ligado, numa plataforma ou numa VPS. Serverless não mantém a conexão aberta.
• API REST com tráfego constante: plataforma de containers ou VPS. Custo previsível e sem cold start.
• Servidor WebSocket ou de tempo real: container. Veja como hospedar um servidor WebSocket.
• Site em Next.js com renderização no servidor: container com next start, ou uma plataforma que suporte Next.js. Veja como hospedar um app Next.js.
• Webhook ou tarefa curta com tráfego raro: serverless tende a compensar.
• Você quer aprender Linux e redes: VPS. O tempo de administração vira estudo, não custo.
• Vários serviços e uma equipe de infraestrutura: orquestração.

Se ficou entre duas opções, escolha a que exige menos manutenção para o seu caso. Migrar depois é simples quando o código segue as regras da próxima seção.

O que vale em qualquer hospedagem?#

Um app Node.js bem preparado roda em qualquer uma das opções acima. Os pontos que mais evitam problemas:

• Use a versão LTS ativa do Node.js. É a que recebe correções por mais tempo; o calendário oficial mostra qual é e quando cada versão sai de suporte.
• Leia a porta e os segredos do ambiente. Nunca fixe senha nem token no código: use variáveis de ambiente.
• Instale a partir do lockfile com npm ci, e deixe em dependencies tudo o que o app importa em runtime.
• Escreva logs no stdout, e não em arquivos que ninguém lê.
• Exponha uma rota de saúde e trate o sinal SIGTERM, que hospedagens e supervisores enviam antes de parar o processo.

Um servidor mínimo que segue essas regras, sem dependências:

import http from "node:http";

const port = Number(process.env.PORT) || 3000;

const server = http.createServer((req, res) => {
  if (req.url === "/health") {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ status: "ok", uptime: process.uptime() }));
    return;
  }
  res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
  res.end("Olá do Node.js\n");
});

server.listen(port, () => console.log(`Ouvindo na porta ${port}`));

// Encerra com calma quando a plataforma pede (deploy novo, restart)
process.on("SIGTERM", () => {
  console.log("SIGTERM recebido, fechando conexões");
  server.close(() => process.exit(0));
});

Salve como index.mjs e rode com node index.mjs. Em http://localhost:3000/health deve aparecer {"status":"ok",...}. O server.close() para de aceitar conexões novas, fecha as ociosas e chama o callback quando as requisições em andamento terminam.

Como fazer isso na Square Cloud#

Na Square Cloud, uma aplicação Node.js segue o modelo de plataforma de containers da tabela: cada aplicação roda num container isolado, sempre ligado, sem cold start nem modo de suspensão. O reinício automático vem ligado no deploy pelo painel e religa o processo que encerra com erro, então você não precisa do PM2. Você envia o código por upload de ZIP no painel, pela CLI, pelo GitHub (GitHub Action oficial ou webhook) ou pela extensão do VS Code.

As regras da seção anterior valem aqui do mesmo jeito. No start, a plataforma roda npm install quando não existe node_modules, com NODE_ENV=production: o que está em devDependencies não é instalado, por isso tudo o que o app importa precisa estar em dependencies. Não há etapa de build, então compile no CI ou coloque o build no comando de início. A aplicação web escuta em 0.0.0.0, na porta da variável PORT, que a plataforma define, e o que você escreve no stdout aparece nos logs em tempo real do painel. As variáveis de ambiente valem no próximo restart, sem reenviar o código.

A RAM do plano é um pool compartilhado: no mínimo 256 MB por aplicação de fundo, como um bot, e 512 MB por aplicação web. O Hobby começa em R$ 12,49 por mês, com 1 GB de RAM e 1 vCPU. Não há autoscaling: você define a RAM de cada aplicação e, a partir do Standard, pode distribuir um domínio entre várias aplicações com load balancing. Entre diversos runtimes, como Node.js, TypeScript (sem etapa de build) e Python, veja os disponíveis hoje em Runtimes e os recursos de deploy em Recursos.