Como Executar Node.js em um VPS

Heroku encerrou seu plano gratuito e aumentou o limite mínimo. Vercel cobra por assento e encerra tarefas de longa duração. Render e Railway ajustam o preço conforme o tráfego.

Abrir a fatura mais recente do seu provedor de hospedagem. O aplicativo Node, um banco de dados Postgres e um cache Redis. Três itens, três conjuntos de avisos de excesso, uma conversa frenética no Slack no dia em que o marketing finalmente lança uma campanha.

Essa fatura é o motivo pelo qual muitas equipes estão reconsiderando o VPS. O Node.js por si só não se importa onde ele é executado. A única coisa que o serverless protegia você era de descobrir o que acontece após o ‘npm start’.

Vamos analisar um padrão de configuração de produção para Node.js em um servidor Linux que você controla. Se você pode acessar um servidor via SSH e ler um arquivo de configuração, ao final, você terá uma pilha de produção que pode executar por anos com algumas horas de manutenção por mês.

Quando Faz Sentido Executar Node.js em um VPS?

Um VPS é o lar certo para Node.js quando você tem um processo de longa duração, uma pilha que deseja consolidar em uma única fatura, ou uma fatura de tempo de execução gerenciado que superou a conveniência.

De modo geral, existem três boas opções:

• Processos de Longa Duração: Servidores WebSocket, trabalhadores de fila, agendadores de Cron Job, servidores MCP. Tudo que precisa permanecer em execução e escuta. A maioria das plataformas serverless ainda otimiza em torno da execução de curta duração e ciclos de vida de solicitação. Um processo Node em um VPS simplesmente fica lá.
• Consolidação de Custos: Aplicativo Node, Postgres, Redis, além de um pequeno trabalhador de construção todos vivem na mesma caixa de 4 GB. Uma linha de fatura, não quatro.
• Aplicativos que Superaram PaaS: Tempos de expiração de função no seu trabalho de geração de PDF longo. Preços por assento em um time que finalmente contratou um quarto engenheiro. Uma fatura do Heroku ultrapassando $60 por mês por uma carga de trabalho que funciona bem em um VPS de $15.

E existem três erros:

• Sites Estáticos e Conteúdo SSG: Um export Next.js, um build Astro, um blog Gatsby. O nível gratuito da Vercel é a ferramenta certa. Um VPS é exagero.
• Cargas de Trabalho Esparsas e Orientadas por Eventos: AWS Lambda ou Cloudflare Workers custam centavos para um webhook que roda dez vezes ao dia. Um VPS custa o mesmo, esteja o aplicativo ocupado ou em repouso.
• Aplicações em Tempo Real Escaladas Horizontalmente: Se o seu servidor WebSocket precisa distribuir para 100.000 conexões simultâneas, um VPS não é a resposta. Isso é um cluster Kubernetes, uma infraestrutura de borda distribuída ou uma plataforma de tempo real gerenciada.

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 dos desenvolvedores executarem JavaScript no backend. Isso representa muitas pessoas executando Node em algum lugar. Este artigo é para a parcela delas que ficaria mais feliz executando-o em um servidor que controlam.

Eu vi equipes transferirem quatro serviços Node de produção do Heroku para um único VPS de 4 GB, com a mesma garantia de uptime, um terço da conta e WebSockets de longa duração que finalmente funcionaram sem necessidade de soluções alternativas.

A migração é principalmente uma tarde de ‘apt install,’ um ‘pm2 start,’ e uma mudança de DNS.

Quais Especificações de VPS o Node.js Realmente Precisa?

O Node.js por si só é leve. Um servidor Express mínimo pode ficar bem abaixo de 100 MB de memória residente. O conselho de que “Node só precisa de 1 GB” que você ainda encontra em blogs antigos é tecnicamente verdadeiro e praticamente inútil. Até o momento em que você adiciona Postgres, Redis, registros e um processo de implantação que não é mantido apenas com esperança, você já está ultrapassando isso em um dia tranquilo.

Dimensionamento realista para cargas de trabalho comuns:

Carga de Trabalho	RAM	vCPU	Armazenamento	Notas
API Express pequena, sem DB na caixa	2 GB	1-2	40 GB NVMe	Piso realista para uma aplicação em produção
API Node + Postgres + Redis em uma caixa	4 GB	2	80 GB NVMe	O ponto ideal; a maioria das equipes chega aqui
Aplicativo pesado em SSR (Next.js, Nuxt, Remix)	8 GB	4	80 GB NVMe	A renderização SSR e as pipelines de construção são onde vai a memória
Aplicativo em tempo real/WebSocket, escala moderada	8 GB	4	80 GB NVMe	Cada conexão persistente consome memória

Alguns detalhes específicos para definir antes de provisionar:

• O Armazenamento NVMe é Mais Importante que o Tamanho Bruto do Disco: Aplicativos modernos Node tocam milhares de pequenos arquivos durante instalações, builds e inicializações. Discos lentos pioram notavelmente as instalações de dependências, inicializações frias e reconstruções de SSR.
• Virtualização KVM, não OpenVZ: Planos antigos baseados em OpenVZ compartilham um 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 respeitáveis são agora exclusivamente KVM, mas ainda vale a pena verificar.
• Espaço de Swap: Ative de 1-2 GB de swap em máquinas menores. O heap V8 do Node pode variar intensamente durante a coleta de lixo. Sem swap, um pico transitório mata o processo. Já vi uma máquina de 4 GB dar OOM durante um deploy rotineiro porque alguém desativou o swap pensando que era um anacronismo da era Docker.
• Largura de Banda: A maioria dos planos modernos de VPS inclui de 1-4 TB de largura de banda mensal, suficiente para quase tudo, exceto hospedagem de vídeo. Planos VPS Auto-Gerenciados incluem largura de banda ilimitada, uma preocupação a menos na planilha de planejamento de capacidade.

Um VPS de 4 GB custa cerca de $15 por mês na taxa de mercado. Isso é 50 centavos por dia, ou aproximadamente um café do aeroporto a cada duas semanas. Comparado a pagar separadamente por runtimes de aplicativos, Postgres gerenciado e Redis em uma PaaS, a economia muda surpreendentemente rápido.

Qual Versão do Node.js Você Deve Instalar?

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

Muitos tutoriais ainda direcionam as pessoas para o Node 22. Esses guias não foram atualizados. Se você está iniciando uma nova implantação hoje, fixe sua imagem CI e seu VPS para o Node 24.x.

Versão	Codinome	Status	EOL
Node.js 26.x	(nenhum)	Atual	Avança para LTS no final de 2026
Node.js 24.x	Krypton	LTS Ativo	Abril de 2028
Node.js 22.x	Jod	LTS de Manutenção	Abril de 2027
Node.js 20.x	Iron	Fim de vida	Atingido EOL em 30 de abril de 2026. Não use.

Algumas regras básicas:

• Não execute versões Current (não-LTS) em produção: Node 26 existe para testar compatibilidade futura e novas funcionalidades de tempo de execução, e não para o aplicativo do qual sua receita depende.
• Node 22 é a opção de fallback se uma dependência crítica ainda não for compatível com Node 24: A maioria do ecossistema se estabilizou dentro de alguns meses após a promoção LTS.
• Fixe sua versão do Node em todos os lugares: Sua imagem CI, Dockerfile, .nvmrc e VPS de produção devem estar todos alinhados. “Funciona no meu computador” torna-se caro rapidamente assim que módulos nativos entram na conversa.

🤔Considerando o Bun? É mais rápido em algumas cargas de trabalho e genuinamente impressionante, mas o ecossistema ainda é menor e o histórico de produção é mais curto do que o do Node. Para a maioria das equipes, o convencional vence.

NodeSource, que mantém os repositórios apt e yum de onde muitas equipes de produção instalam o Node, destaca melhorias na linha 24.x, começando com um motor V8 mais novo. O Node 24 também agora conta com ferramentas maduras como node –watch integrado e um executor de testes nativo estável (node: test), ambos estabilizados nas linhas 20–22 e que continuam a partir daqui. Nada disso é chamativo. Apenas remove um pouco do atrito operacional todos os meses.

Como Instalar o Node.js em um VPS?

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

NodeSource Para Um Servidor De Aplicação Única

Este é o caminho de produção mais simples. Um script de configuração e um apt install fornecem a você a linha atual do Node 24 LTS como um pacote do sistema, e futuras atualizações de segurança são realizadas através de upgrades 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 Node 24.x.

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

nvm para Alternância de Versão Por Projeto

nvm (Gerenciador de Versão do Node) instala o Node em seu diretório pessoal e permite que diferentes projetos executem diferentes versões do Node. Útil se você hospedar múltiplos aplicativos no mesmo servidor ou não tiver acesso sudo.

Execute isso como seu usuário de aplicativo, não como Root:

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

Recarregue seu shell e, em seguida, instale o Node 24:

nvm install 24
nvm use 24
nvm alias default 24

👉Regra Importante: Não use sudo ‘npm install -g’ para dependências de aplicativos.

Instalações globais são geralmente reservadas para ferramentas CLI de nível de máquina como pm2, typescript ou nodemon. As dependências do seu aplicativo devem estar em package.json e devem ser instaladas a partir do diretório do projeto com npm ci.

NodeSource	nvm
Uma versão do Node por servidor	Várias versões do Node por servidor
Instalado em todo o sistema, executa como qualquer usuário	Instalado por usuário
Atualizações automáticas com ‘apt’	Gerenciado manualmente
Requer sudo	Não requer sudo

Se você está em dúvida, comece com o NodeSource. A maioria dos servidores de produção de propósito único não precisa de troca de versão do Node por projeto.

👉Usuários do VPS Auto-Gerenciado da DreamHost: O aplicativo Node disponível no provisionamento vem com o Node 22 LTS — ainda com suporte até abril de 2027. Para executar o Node 24, use os passos do NodeSource ou nvm mencionados acima após o provisionamento.

Deveria Usar PM2 ou systemd Para Manter Sua Aplicação Funcionando?

Qualquer um funciona. A resposta honesta é qual sua equipe se sente mais confortável utilizando. PM2 é o caminho amigável para desenvolvedores. systemd é o caminho nativo Unix. Ambos resolvem os mesmos três problemas: reiniciar em caso de falha, iniciar no boot e desligamento suave ao receber um ‘SIGTERM’.

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

	PM2	systemd
Tempo de Configuração	3 minutos	10 minutos
Modo Cluster (multi-core)	Integrado	Não integrado (iniciar N unidades)
Rotação de Logs	Módulo: ‘pm2-logrotate’	Integrado via ‘journalctl’
Recarga Sem Interrupção	‘pm2 reload’	Normalmente manipulado manualmente com reinícios escalonados ou múltiplas unidades
Sobrecarga de Memória (daemon)	Sobrecarga pequena de daemon	Nenhuma (sem daemon extra)
Melhor para	Caixa única, loja JS, iteração rápida	Caixas multi-aplicativos, conforto da equipe de operações

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

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # imprime o comando de inicialização do systemd a ser executado
pm2 save       # salva a lista de processos atual

O PM2 então se torna a única coisa com a qual você conversa: ‘pm2 logs,’ ‘pm2 reload api,’ ‘pm2 monit.’

👉Também Vale Saber: ‘pm2 startup’ escreve uma unidade systemd, então a configuração do PM2 realmente utiliza systemd por debaixo dos panos.

Uma unidade systemd mínima para gerenciamento direto do Node em ‘/etc/systemd/system/api.service’:

[Unit]
Descrição=Minha API Node
Depois=network.target

[Serviço]
Type=simple
User=app
WorkingDirectory=/var/www/api
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
Então ‘systemctl enable --now api.’ Os registros estão em ‘journalctl -u api -f.’

Se você já está executando PM2 e está funcionando, não migre para systemd só porque alguém no Hacker News disse isso. A memória do daemon PM2 não é o motivo pelo qual você migraria dele.

Migre quando tiver um motivo real, como rodar meia dúzia de processos Node onde cada megabyte conta, ou integrar em um ambiente operacional onde todo outro serviço é uma unidade systemd, e o PM2 se destaca como o discrepante.

Como Colocar NGINX (ou Caddy) na Frente do Seu Aplicativo Node?

Você deseja um proxy reverso na frente do Node por cinco razões: término de HTTPS, compressão gzip/brotli, entrega de ativos estáticos, execução de múltiplos aplicativos na mesma máquina e limitação de taxa mais fácil. Node pode fazer todas essas coisas. NGINX e Caddy fazem-nas melhor, e eles não derrubam seu loop de eventos quando algo se comporta mal.

Escolha NGINX se alguém da sua equipe já o conhece. Escolha Caddy se você quiser HTTPS em três linhas de configuração e estiver satisfeito com um ecossistema de configuração avançada menor.

Configuração Mínima do NGINX

Coloque este bloco de proxy em /etc/nginx/sites-available/api, crie um link simbólico para sites-enabled, depois 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 do WebSocket. Os próprios documentos do NGINX mencionam que o Upgrade é um cabeçalho de salto a salto, por isso precisa de tratamento explícito ao fazer proxy do tráfego WebSocket.

Deixe-os ativados se sua aplicação usa WebSockets agora ou poderá usar mais tarde. Socket.IO, assinaturas GraphQL sobre WebSockets e um número surpreendente de funcionalidades em tempo real “regulares” dependem desse handshake de atualização.

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

Caddyfile Mínimo

A versão Caddy reverse proxy quickstart da 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 provisionamento automático de HTTPS emite certificados TLS para os sites e os mantém renovados; sua introdução rápida ao proxy reverso também indica que o HTTPS é automático quando o Caddy conhece o nome do host.

Vincular Nó a localhost, Não a 0.0.0.0

Independentemente do proxy que escolheres, configura a tua aplicação Node para ouvir em 127.0.0.1:3000, não em 0.0.0.0:3000. A única coisa que deve enfrentar a internet pública num servidor Node é o proxy. Emparelha isso com o UFW, o frontend comum de firewall do Ubuntu, para negar 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 estiver em uma porta personalizada, permita essa porta antes de ativar o UFW.

Ligue-se ao localhost desde o primeiro dia. A reunião onde alguém admite “o aplicativo estava exposto porque o Node se ligou a 0.0.0.0” não é uma reunião que você deseja ter.

Como Configurar HTTPS Para Seu Aplicativo Node.js?

Use Let’s Encrypt. É gratuito, automatizado e confiado por todos os navegadores. Existem dois caminhos, dependendo de qual proxy você escolheu.

NGINX + Certbot

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

Instale o Certbot:

apt install certbot python3-certbot-nginx

Execute:

certbot --nginx -d api.example.com

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

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

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

A documentação oficial do Certbot também aborda o caminho de instalação baseado em snap se o pacote da sua distribuição estiver desatualizado.

Caddy

Adicione o domínio ao Caddyfile (o exemplo acima já o possui), depois reinicie o Caddy. Contanto 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 há Certbot.

Não termine o TLS no próprio Node para produção.

O módulo https do Node funciona perfeitamente, mas proxies reversos como NGINX e Caddy são projetados 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 logo após a instalação.

Conseguirias gerir tudo isso diretamente em Node? Com certeza. Apenas estarias a reconstruir infraestrutura que o teu proxy já resolve extremamente bem.

Como É Realmente Um Setup De Node.js Pronto Para Produção?

Oito coisas mordem pessoas em produção. A maioria delas não está nos tutoriais de instalação porque não se encaixam no arco “instalar Node, executar aplicativo”. Elas são a diferença entre um aplicativo que sobrevive ao segundo mês e um que não sobrevive.

• NODE_ENV=production: O passo mais esquecido. Em muitos frameworks e bibliotecas Node, ele desativa comportamentos exclusivos de desenvolvimento e habilita 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 — seus próprios documentos citam até uma melhoria de desempenho de 3x. Defina a ‘env var’ em todos os lugares.
• Encerramento Gracioso: Quando o seu VPS reinicia ou o PM2 envia ‘SIGTERM’, seu aplicativo tem alguns segundos para drenar requisições em andamento, fechar conexões de banco de dados e sair de forma limpa. Configure um manipulador ‘process.on(‘SIGTERM’, …)’. O tempo de desligamento padrão do PM2 depende da configuração e do ambiente, então não assuma que sempre terá muito tempo para limpar.
• Rotação de Logs: O módulo ‘pm2-logrotate’ do PM2 cuida disso para o PM2. O jornal systemd cuida disso para unidades systemd diretas. Sem rotação, seus logs consomem o disco em um quarto do tempo que você esperaria.
• Disciplina .env: Nunca cometa segredos, nunca os registre. Use ‘dotenv’ para desenvolvimento local. Na produção, defina variáveis de ambiente via ‘Environment=’ da sua unidade systemd ou seu arquivo de ecossistema PM2. O dia em que você ‘console.log(process.env)’ por acidente é o dia em que você rotaciona todas as credenciais.
• Um proxy reverso na frente do Node: Associe o Node ao localhost; deixe o NGINX ou o Caddy enfrentar a internet pública.
• Um firewall: UFW nega tudo exceto 22, 80, 443. Mudar o SSH para longe da porta 22 não impede um atacante determinado, mas reduz drasticamente o ruído de força bruta automatizado e os registros de autenticação inúteis.
• Monitoramento: Um ponto de verificação de saúde que sua ferramenta de monitoramento verifica a cada minuto. O PM2 possui fundamentos básicos. Para algo mais sério, use Prometheus e Grafana, ou utilize um serviço de uptime hospedado como Better Stack ou UptimeRobot. Você quer saber que seu aplicativo está fora do ar antes de um cliente informar.

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

Atualizações do Apt, atualizações ocasionais de dependências e uma análise trimestral do volume de registros. Essa é a troca pelo custo e pelos ganhos de controle.

Quando Um VPS É A Escolha Errada Para Node.js?

Um VPS é a escolha errada quando sua carga de trabalho é construída para algo diferente. Seja honesto sobre qual lado você está antes de provisionar.

• Sites estáticos e conteúdo SSG: Exportação Next.js, Astro, Gatsby e um blog Eleventy. Plataformas como Vercel, Netlify ou Cloudflare Pages oferecem hospedagem estática globalmente cacheada, implantações baseadas em Git e reconstruções automáticas prontas para uso. Um VPS geralmente é uma infraestrutura desnecessária para conteúdo puramente estático.
• Cargas de trabalho esporádicas e orientadas por eventos: Cloudflare Workers e AWS Lambda são econômicos para webhooks que funcionam dez vezes por dia. 
• Aplicativos em tempo real que precisam de mais de 100.000 conexões simultâneas: Um VPS não escala horizontalmente. Você precisará de orquestração (Kubernetes, ECS, Nomad) ou de uma plataforma em tempo real gerenciada como Ably ou Pusher.
• Cargas de trabalho regulamentadas com muitas exigências de conformidade: HIPAA, PCI-DSS Nível 1, FedRAMP. Um PaaS gerenciado com certificações de conformidade integradas economiza o trabalho de auditoria. A auto-hospedagem de conformidade em um VPS é um projeto de vários trimestres que você provavelmente não quer.
• Nenhum conforto com Linux — e sem vontade de desenvolvê-lo: Plataformas como Render, Railway e DigitalOcean App Platform ficam em algum lugar entre a hospedagem VPS bruta e o PaaS totalmente gerenciado. Ferramentas como Dokploy adicionam fluxos de trabalho de implantação ao estilo Heroku em cima de sua própria infraestrutura VPS. Você ainda obtém muitos dos benefícios de custo e controle sem precisar se aprofundar em iptables, internos do systemd ou depuração de proxy reverso à 1 da manhã.

Não há vergonha em nenhuma dessas respostas. A melhor decisão técnica é aquela que corresponde à sua carga de trabalho.

Escolhendo Seu Node Stack e Mudando-se

Abre essa fatura de hospedagem mais uma vez.

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

👉A pilha: Ubuntu 24.04 LTS, Node 24, PM2 (ou systemd), NGINX (ou Caddy), Let’s Encrypt via Certbot (ou integrado ao Caddy).

Ative o menor plano de VPS que atenda à RAM que você dimensionou, instale o Node, execute seu aplicativo em ‘127.0.0.1’, direcione o NGINX para ele e altere seu DNS.

Se o aplicativo sobrevive a uma implantação, um reinício e uma execução noturna sem problemas, você já está quase lá.

O resto é manutenção. Uma ou duas horas por mês, a janela ocasional de ‘apt upgrade’, um aumento de dependência trimestral. Esse é o acordo que você fez quando trocou uma fatura por assento por uma fixa, e a Self-Managed VPS Stack 4 da DreamHost é onde você pode começar.

Perguntas Frequentes Sobre a Execução do Node.js em um VPS

Posso executar Node.js em qualquer VPS?

A maioria dos planos modernos de VPS roda Node.js sem problemas. Planos VPS baseados em KVM com uma distribuição Linux de 64 bits são a opção padrão mais segura para as versões atuais do Node.js.

Planos mais antigos baseados em OpenVZ às vezes têm restrições de kernel que prejudicam as versões mais recentes do Node. Se você estiver escolhendo entre provedores, pergunte se eles são baseados em KVM.

Quanta RAM o Node.js precisa em um VPS?

Um servidor Express mínimo fica bem abaixo de 100 MB em ociosidade, mas um aplicativo de produção realista com middleware, registro em log e um pool de conexões geralmente opera na faixa de 150-300 MB.

O mínimo realista para um aplicativo em produção é de 2 GB; o ponto ideal para uma pilha Node + Postgres + Redis é de 4 GB. DreamHost’s Self-Managed VPS Stack 4 (4 GB) lida com a maioria das cargas de trabalho de produção Node. Avance para a Stack 8 (8 GB) para aplicativos com SSR pesado ou em tempo real.

Qual é a versão LTS atual do Node.js?

A versão LTS ativa atual é o Node.js 24.x (“Krypton”), promovido em 28 de outubro de 2025 e suportado até abril de 2028. O Node.js 22.x (“Jod”) está em Manutenção LTS até abril de 2027, se uma dependência exigir compatibilidade retroativa. Node.js 26 foi lançado em 5 de maio de 2026, como Atual e será promovido a LTS em outubro de 2026.

A maioria das equipes de produção adere às versões LTS, a menos que precisem especificamente de recursos de runtime mais recentes.

Preciso do PM2 se eu tenho systemd?

Não, você não precisa de ambos. PM2 e systemd resolvem o mesmo problema: manter seu aplicativo Node funcionando através de falhas e reinicializações. Muitas equipes focadas em Node escolhem o PM2 pelo clustering integrado, gerenciamento de logs e ferramentas de recarregamento.

Equipes que já utilizam unidades systemd para tudo escolhem systemd.

Por que colocar o NGINX na frente do Node.js?

NGINX (ou Caddy) à frente do Node.js centraliza a terminação TLS, compressão, entrega de ativos estáticos e limitação de taxa em software projetado especificamente para proxy e serviço web.

Também permite que você execute múltiplos aplicativos Node no mesmo VPS sem conflitos de porta. Na produção, o Node escuta no localhost; o NGINX fica voltado para a internet pública.

O Node.js em um VPS é mais barato que o Heroku ou Vercel?

Sim, frequentemente. Um VPS de 4 GB geralmente está na faixa de $15-$25 por mês a taxas de mercado e pode consolidar os custos de runtime de aplicativos, banco de dados e cache que são cobrados separadamente em muitas plataformas PaaS.

O preço do Vercel Pro é baseado em assentos, e as plataformas sem servidor ainda impõem limites de duração de execução dependendo do tempo de execução e do plano.

O acordo é que você mesmo gerencie as operações, cerca de uma a três horas por mês.

Posso executar múltiplos aplicativos Node em um único VPS?

Sim, e é a razão mais comum pela qual as equipes migram de PaaS para um VPS. Execute cada aplicativo em sua própria porta interna (3000, 3001, 3002) e direcione o tráfego com blocos de servidor NGINX por nome de host. PM2 gerencia todos eles como processos separados; systemd usa um arquivo de unidade por aplicativo.

Um VPS de 4 GB geralmente pode lidar com vários serviços leves de Node juntamente com uma pequena carga de trabalho de banco de dados.

Posso Executar Node.js No Shared Hosting Da DreamHost?

Não. Node.js necessita de processos persistentes, instalações de pacotes em nível de Root e vinculação direta de porta, nenhum dos quais é fornecido pelo Shared Hosting. Os planos VPS Auto-Gerenciados da DreamHost (Stack 4 e superiores) são adequados para cargas de trabalho Node com acesso total ao root, armazenamento NVMe e largura de banda ilimitada.