Como rodar Node.js em uma VPS

O Heroku acabou com o plano gratuito e aumentou o preço mínimo. A Vercel cobra por usuário e interrompe tarefas longas por timeout. Render e Railway escalam o preço conforme o tráfego.

Abra a fatura mais recente do seu provedor de hospedagem. O app Node, um banco de dados Postgres e um cache Redis. Três itens na conta, três conjuntos de alertas de excedente e uma thread desesperada no Slack no dia em que o marketing finalmente lança uma campanha.

É por causa dessa fatura que muitas equipes estão dando uma nova chance à VPS. O Node.js em si não se importa com onde roda. A única coisa da qual o serverless protegia você era descobrir o que acontece depois do “npm start”.

Vamos ver um padrão de configuração de produção para Node.js em uma máquina Linux que você controla. Se você consegue acessar uma máquina via SSH e ler um arquivo de configuração, ao final terá uma stack de produção que pode rodar por anos com umas duas horas de manutenção por mês.

Quando faz sentido rodar Node.js em uma VPS?

A VPS é o lugar certo para o Node.js quando você tem um processo de longa duração, uma stack que quer consolidar em uma única fatura ou uma conta de runtime gerenciado que já não compensa pela conveniência.

De modo geral, há três casos em que faz sentido:

• Processos de longa duração: servidores WebSocket, workers de fila, agendadores cron, servidores MCP. Qualquer coisa que precise continuar rodando e escutando. A maioria das plataformas serverless ainda é otimizada para execuções curtas e ciclos de vida de requisição. Um processo Node em uma VPS simplesmente fica lá, rodando.
• Consolidação de custos: app Node, Postgres, Redis e um pequeno worker de build convivem na mesma máquina de 4 GB. Uma linha na fatura, não quatro.
• Apps que superaram o PaaS: timeouts de função no seu job demorado de geração de PDF. Cobrança por usuário em uma equipe que finalmente contratou o quarto engenheiro. Uma fatura do Heroku passando de US$ 60 por mês para uma carga de trabalho que roda bem em uma VPS de US$ 15.

E há três casos em que não faz sentido:

• Sites estáticos e conteúdo SSG: um export do Next.js, um build do Astro, um blog em Gatsby. O plano gratuito da Vercel é a ferramenta certa. Uma VPS é exagero.
• Cargas esparsas e orientadas a eventos: AWS Lambda ou Cloudflare Workers custam centavos para um webhook que roda dez vezes por dia. Uma VPS custa o mesmo, esteja o app ocupado ou parado.
• Apps em tempo real com escala horizontal: se o seu servidor WebSocket precisa distribuir para 100.000 conexões simultâneas, uma VPS não é a resposta. Isso pede um cluster Kubernetes, uma infraestrutura de edge distribuída ou uma plataforma gerenciada de tempo real.

JavaScript é a linguagem mais usada na Pesquisa de Desenvolvedores do Stack Overflow de 2025, e o Node.js continua sendo uma das formas padrão de rodar JavaScript no backend. É muita gente rodando Node em algum lugar. Este artigo é para a parcela dessas pessoas que ficaria mais feliz rodando o Node em um servidor sob o próprio controle.

Já vi equipes migrarem quatro serviços Node de produção do Heroku para uma única VPS de 4 GB, com o mesmo uptime, um terço da fatura e WebSockets de longa duração que finalmente funcionaram sem precisar de soluções alternativas.

A migração se resume basicamente a uma tarde de “apt install”, um “pm2 start” e uma alteração de DNS.

De quais especificações de VPS o Node.js realmente precisa?

O Node.js em si é leve. Um servidor Express mínimo pode ficar ocioso com bem menos de 100 MB de memória residente. O conselho de que o Node só precisa de 1 GB, que você ainda encontra em blogs antigos, é tecnicamente verdadeiro e, na prática, inútil. Quando você adiciona Postgres, Redis, logs e um processo de deploy que não se sustenta só na esperança, já passou disso em um dia tranquilo.

Dimensionamento realista para cargas de trabalho comuns:

Alguns detalhes para definir antes de provisionar:

• Armazenamento NVMe importa mais que o tamanho bruto do disco: apps Node modernos acessam milhares de arquivos pequenos durante instalações, builds e inicialização. Discos lentos deixam visivelmente piores as instalações de dependências, as inicializações a frio e os rebuilds de SSR.
• Virtualização KVM, não OpenVZ: planos mais antigos baseados em OpenVZ compartilham o kernel com o host, o que pode significar versões de kernel desatualizadas e dores de cabeça ocasionais de compatibilidade com runtimes mais novos. A maioria dos provedores de VPS confiáveis hoje usa apenas KVM, mas vale conferir.
• Espaço de swap: habilite de 1 a 2 GB de swap em máquinas menores. O heap do V8 no Node pode oscilar bastante durante a coleta de lixo. Sem swap, um pico passageiro derruba o processo. Já vi uma máquina de 4 GB sofrer OOM durante um deploy de rotina porque alguém tinha desabilitado o swap achando que era um anacronismo da era Docker.
• Largura de banda: a maioria dos planos de VPS modernos inclui de 1 a 4 TB de largura de banda mensal, o suficiente para quase tudo, exceto hospedagem de vídeo. Os planos de VPS autogerenciado incluem largura de banda ilimitada, uma linha a menos na planilha de planejamento de capacidade.

Uma VPS de 4 GB custa em torno de US$ 15 por mês a preço de mercado. São 50 centavos por dia, ou mais ou menos um café de aeroporto a cada duas semanas. Comparado a pagar separadamente por runtimes de app, Postgres gerenciado e Redis em um PaaS, a conta se inverte surpreendentemente rápido.

Qual versão do Node.js você deve instalar?

Instale o Node.js 24 (codinome Krypton). É a versão Active LTS atual, promovida em outubro de 2025 e com suporte até abril de 2028, segundo o cronograma oficial de lançamentos do Node.js.

Muitos tutoriais ainda indicam o Node 22. Esses guias não foram atualizados. Se você vai começar um novo deploy hoje, fixe sua imagem de CI e sua VPS no Node 24.x.

Algumas regras práticas:

• Não rode versões Current (não LTS) em produção: o Node 26 existe para testar compatibilidade futura e novos recursos do runtime, não para o app do qual sua receita depende.
• O Node 22 é a opção de reserva se uma dependência crítica ainda não for compatível com o Node 24: a maior parte do ecossistema se estabilizou poucos meses após a promoção a LTS.
• Fixe a versão do Node em todo lugar: sua imagem de CI, o Dockerfile, o .nvmrc e a VPS de produção devem estar alinhados. O famoso na minha máquina funciona fica caro rapidinho quando módulos nativos entram em cena.

🤔Pensando no Bun? Ele é mais rápido em algumas cargas de trabalho e realmente impressionante, mas o ecossistema ainda é menor e o histórico em produção é mais curto que o do Node. Para a maioria das equipes, o simples e previsível vence.

A NodeSource, que mantém os repositórios apt e yum dos quais muitas equipes de produção instalam o Node, destaca melhorias na linha 24.x, a começar por um motor V8 mais novo. O Node 24 também traz ferramentas já maduras, como o node –watch integrado e um executor de testes nativo estável (node: test), ambos estabilizados nas linhas 20–22 e mantidos aqui. Nada disso é chamativo. Só elimina um pouco de atrito operacional todo mês.

Como instalar o Node.js em uma VPS?

Você tem dois caminhos realistas de instalação. Escolha com base em se o servidor roda um app Node ou vários.

NodeSource para um servidor com um único app

Este é o caminho de produção mais simples. Um script de configuração e um apt install trazem a linha atual do Node 24 LTS como pacote do sistema, e as futuras atualizações de segurança chegam pelas atualizações normais de pacotes.

No Ubuntu ou Debian:

curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs

Verifique a instalação:

node -v
npm -v

Você deve ver uma versão 24.x do Node.

As instruções para distros da família RHEL (yum/dnf) estão no repositório oficial de distribuições da NodeSource.

nvm para alternar versões por projeto

O nvm (Node Version Manager) instala o Node no seu diretório home e permite que projetos diferentes usem versões diferentes do Node. É útil se você hospeda vários apps no mesmo servidor ou não tem acesso sudo.

Execute isto com o usuário da aplicação, não como root:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash

Recarregue o Shell e depois instale o Node 24:

nvm install 24
nvm use 24
nvm alias default 24

👉Uma regra importante: não use sudo ‘npm install -g’ para dependências da aplicação.

Instalações globais costumam ser reservadas para ferramentas de CLI da máquina, como pm2, typescript ou nodemon. As dependências do seu app ficam no package.json e devem ser instaladas a partir do diretório do projeto com npm ci.

Se estiver em dúvida, comece com a NodeSource. A maioria dos servidores de produção de propósito único não precisa alternar a versão do Node por projeto.

👉Usuários de VPS da DreamHost: o app Node.js disponível no provisionamento já vem com Node.js 24 LTS, além de fnm, PM2, Nginx e SSL com Certbot, então você pode pular as etapas de instalação acima.

PM2 ou systemd: qual usar para manter seu app rodando?

Os dois funcionam. A resposta honesta é: aquele com que sua equipe se sente mais à vontade. O PM2 é o caminho amigável para desenvolvedores. O systemd é o caminho nativo do Unix. Ambos resolvem os mesmos três problemas: reiniciar em caso de falha, iniciar no boot e desligar de forma graciosa ao receber “SIGTERM”.

Se você está começando do zero, veja como escolher:

O início rápido do PM2 é exatamente isso, rápido:

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # prints the systemd startup command to run
pm2 save       # saves the current process list

A partir daí, o PM2 passa a ser a única coisa com que você interage: “pm2 logs”, “pm2 reload api”, “pm2 monit”.

👉Também vale saber: “pm2 startup” cria uma unidade systemd, então a configuração do PM2 na verdade usa o systemd por baixo dos panos.

Uma unidade systemd mínima para gerenciar o Node diretamente em “/etc/systemd/system/api.service”:

[Unit]Description=My Node APIAfter=network.target

[Service]Type=simpleUser=appWorkingDirectory=/var/www/apiExecStart=/usr/bin/node server.jsRestart=on-failureRestartSec=5Environment=NODE_ENV=productionStandardOutput=journalStandardError=journal

[Install]WantedBy=multi-user.target
Depois, “systemctl enable --now api”. Os logs ficam em “journalctl -u api -f”.

Se você já usa o PM2 e ele está funcionando, não migre para o systemd só porque alguém no Hacker News falou. A memória do daemon do PM2 não é motivo para abandoná-lo.

Migre quando tiver um motivo real, como rodar meia dúzia de processos Node em que cada megabyte conta, ou entregar para um ambiente de operações em que todos os outros serviços são unidades systemd e o PM2 é o único destoante.

Como colocar o NGINX (ou o Caddy) na frente do seu app Node?

Você quer um proxy reverso na frente do Node por cinco motivos: terminação HTTPS, compressão gzip/brotli, entrega de arquivos estáticos, execução de vários apps na mesma máquina e limitação de taxa mais fácil. O Node consegue fazer tudo isso. O NGINX e o Caddy fazem melhor e não derrubam o seu event loop quando algo dá errado.

Escolha o NGINX se alguém da sua equipe já o conhece. Escolha o Caddy se você quer HTTPS em três linhas de configuração e não se importa com um ecossistema menor de configurações avançadas.

Configuração mínima do NGINX

Coloque este bloco de proxy em /etc/nginx/sites-available/api, crie um symlink em sites-enabled e depois execute nginx -t && systemctl reload nginx.

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Os cabeçalhos “Upgrade” e “Connection” são as linhas de suporte a WebSocket. A própria documentação do NGINX ressalta que Upgrade é um cabeçalho hop-by-hop, por isso precisa de tratamento explícito ao fazer proxy de tráfego WebSocket.

Mantenha-os se o seu app usa WebSockets agora ou pode usar no futuro. Socket.IO, assinaturas GraphQL via WebSockets e um número surpreendente de recursos de tempo real comuns dependem desse handshake de upgrade.

O bug de produção mais comum que vejo em configurações Node é um servidor Socket.IO atrás do NGINX sem essas duas linhas. As conexões falham de forma intermitente, os devs culpam o Socket.IO e o problema real geralmente é a configuração do proxy.

Caddyfile mínimo

A versão do guia de início rápido de proxy reverso do Caddy para a mesma coisa:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Esse é o arquivo inteiro. Desde que o domínio aponte para o servidor e as portas 80/443 estejam acessíveis, o Caddy provisiona e renova o HTTPS automaticamente. A documentação do Caddy diz que o HTTPS automático provisiona certificados TLS para os sites e os mantém renovados. O guia rápido de proxy reverso do Caddy também observa que o HTTPS é automático quando o Caddy conhece o hostname.

Vincule o Node ao localhost, não ao 0.0.0.0

Seja qual for o proxy escolhido, configure seu app Node para escutar em 127.0.0.1:3000, não em 0.0.0.0:3000. A única coisa que deve ficar exposta à internet pública em uma máquina com Node é o proxy. Combine isso com o UFW, o frontend de firewall mais comum do Ubuntu, para bloquear tudo, exceto as portas 22, 80 e 443.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Se o SSH roda em uma porta personalizada, libere essa porta antes de ativar o UFW.

Vincule ao localhost desde o primeiro dia. Você não quer estar naquela reunião em que alguém admite que o app ficou exposto porque o Node estava vinculado a 0.0.0.0.

Como configurar HTTPS para o seu app Node.js?

Use o Let’s Encrypt. Ele é gratuito, automatizado e confiável para todos os navegadores. Há dois caminhos, dependendo do proxy que você escolheu.

NGINX + Certbot

Aponte um registro A para o IP da sua VPS e aguarde a propagação do DNS.

Instale o Certbot:

apt install certbot python3-certbot-nginx

Execute:

certbot --nginx -d api.example.com

O Certbot atualiza a configuração do NGINX e recarrega o servidor automaticamente.

Nas versões recentes do Ubuntu, um timer do systemd instalado pelo pacote do Certbot cuida da renovação automaticamente.

Abra https://api.example.com e confirme se o ícone de cadeado aparece.

A documentação oficial do Certbot também explica a instalação via snap, caso o pacote da sua distro esteja desatualizado.

Caddy

Adicione o domínio ao Caddyfile (o exemplo acima já o inclui) e reinicie o Caddy. Desde que o domínio seja resolvido corretamente e as portas 80/443 estejam acessíveis, o certificado é provisionado automaticamente na primeira inicialização. Não é preciso usar o Certbot.

Em produção, não faça a terminação TLS no próprio Node.

O módulo https do Node funciona perfeitamente, mas proxies reversos como NGINX e Caddy foram feitos especificamente para a terminação TLS. Eles oferecem OCSP stapling, cifras modernas por padrão, renovação automática de certificados, suporte a HTTP/2 e, no caso do Caddy, suporte a HTTP/3 de fábrica.

Dá para fazer tudo isso diretamente no Node? Claro. Mas você estaria apenas reconstruindo uma infraestrutura que o seu proxy já resolve muito bem.

Como é, na prática, uma configuração de Node.js pronta para produção?

Oito coisas costumam dar dor de cabeça em produção. A maioria não aparece nos tutoriais de instalação porque não se encaixa no roteiro instalar o Node, rodar o app. Elas fazem a diferença entre um app que sobrevive ao segundo mês e um que não sobrevive.

• NODE_ENV=production: O passo mais esquecido de todos. Em muitos frameworks e bibliotecas Node, ele desativa comportamentos exclusivos de desenvolvimento e ativa otimizações de produção. O Express, por exemplo, armazena em cache os templates de visualização compilados e retorna erros mais concisos em produção. A própria documentação dele cita uma melhoria de desempenho de até 3x. Defina essa variável de ambiente em todos os lugares.
• Encerramento gracioso: Quando sua VPS reinicia ou o PM2 envia “SIGTERM”, seu app tem poucos segundos para concluir as requisições em andamento, fechar as conexões com o banco de dados e sair de forma limpa. Configure um handler “process.on(‘SIGTERM’, …)”. O tempo padrão de encerramento do PM2 depende da configuração e do ambiente, então não conte com muito tempo para a limpeza.
• Rotação de logs: No PM2, o módulo “pm2-logrotate” cuida disso. Para units do systemd, o journal do systemd faz esse trabalho. Sem rotação, seus logs lotam o disco em um quarto do tempo que você imagina.
• Disciplina com o .env: Nunca faça commit de segredos e nunca os registre em log. Use o “dotenv” no desenvolvimento local. Em produção, defina as variáveis de ambiente pelo “Environment=” da sua unit do systemd ou pelo arquivo ecosystem do PM2. No dia em que você der um “console.log(process.env)” sem querer, vai ter que trocar todas as credenciais.
• Um proxy reverso na frente do Node: Vincule o Node ao localhost e deixe o NGINX ou o Caddy expostos à internet pública.
• Um firewall: Configure o UFW para bloquear tudo, exceto 22, 80 e 443. Tirar o SSH da porta 22 não vai deter um invasor determinado, mas reduz drasticamente o ruído de ataques automatizados de força bruta e o lixo nos logs de autenticação.
• Monitoramento: Um endpoint de healthcheck que sua ferramenta de monitoramento consulta a cada minuto. O PM2 tem o básico integrado. Para algo mais sério, use Prometheus e Grafana ou um serviço hospedado de monitoramento de uptime como o Better Stack ou o UptimeRobot. Você quer saber que seu app caiu antes de um cliente avisar.

Estimativa de manutenção para essa stack: de uma a três horas por mês.

Atualizações via apt, uma ou outra atualização de dependências e uma olhada trimestral no volume de logs. Esse é o preço pelos ganhos em custo e controle.

Quando uma VPS é a escolha errada para Node.js?

Uma VPS é a escolha errada quando sua carga de trabalho foi pensada para outra coisa. Seja honesto sobre em qual lado você está antes de provisionar.

• Sites estáticos e conteúdo SSG: Export do Next.js, Astro, Gatsby e um blog em Eleventy. Plataformas como Vercel, Netlify ou Cloudflare Pages oferecem hospedagem estática com cache global, deploys baseados em Git e rebuilds automáticos de fábrica. Para conteúdo puramente estático, uma VPS costuma ser infraestrutura desnecessária.
• Cargas de trabalho esporádicas e orientadas a eventos: Cloudflare Workers e AWS Lambda saem baratos para webhooks que rodam dez vezes por dia.
• Apps em tempo real que precisam de mais de 100.000 conexões simultâneas: Uma única VPS não escala horizontalmente. Você vai precisar de orquestração (Kubernetes, ECS, Nomad) ou de uma plataforma gerenciada de tempo real como Ably ou Pusher.
• Cargas de trabalho regulamentadas com muitas exigências de conformidade: HIPAA, PCI-DSS Nível 1, FedRAMP. Uma PaaS gerenciada com certificações de conformidade integradas poupa a dor de cabeça das auditorias. Garantir conformidade por conta própria em uma VPS é um projeto de vários trimestres que você provavelmente não quer encarar.
• Sem Linux no currículo — e sem disposição para aprender: Plataformas como Render, Railway e DigitalOcean App Platform ficam em algum ponto entre a hospedagem VPS pura e uma PaaS totalmente gerenciada. Ferramentas como o Dokploy adicionam fluxos de deploy no estilo Heroku sobre a sua própria infraestrutura VPS. Você ainda aproveita boa parte dos benefícios de custo e controle sem precisar dominar iptables, os detalhes internos do systemd ou depurar proxy reverso à 1 da manhã.

Não há vergonha nenhuma em qualquer uma dessas respostas. A melhor decisão técnica é a que combina com sua carga de trabalho.

Como escolher sua stack Node e colocar tudo para rodar

Abra aquela fatura de hospedagem mais uma vez.

Você está prestes a substituir uma parte surpreendente dela por uma única fatura de VPS.

👉A stack: Ubuntu 24.04 LTS, Node 24, PM2 (ou systemd), NGINX (ou Caddy), Let’s Encrypt via Certbot (ou o recurso nativo do Caddy).

Crie o menor plano de VPS que tenha a RAM que você dimensionou, instale o Node, rode seu app em “127.0.0.1”, aponte o NGINX para ele e altere seu DNS.

Se o app sobreviver a um deploy, a uma reinicialização e a uma noite rodando sem sustos, você já percorreu a maior parte do caminho.

O resto é manutenção. Uma ou duas horas por mês, uma janela ocasional de “apt upgrade”, uma atualização trimestral de dependências. Esse é o acordo que você fez ao trocar uma fatura por usuário por uma de valor fixo, e o Stack 4 de VPS autogerenciado da DreamHost é um ótimo ponto de partida.

Perguntas frequentes sobre como rodar Node.js em uma VPS