Node-RED sem desperdício: escolher VPS para Node-RED é dimensionar CPU, memória e disco pelo consumo real dos fluxos, do dashboard e dos serviços no mesmo host — não existe um tamanho único, e núcleo ocioso não deixa o runtime mais estável. Para escolher o plano sem desperdício, siga estes passos:
- Inventarie fluxos, dashboard, broker MQTT e qualquer banco no mesmo servidor
- Rode a automação real por alguns dias em um plano pequeno no Ubuntu 24.04 LTS
- Meça o RSS do processo Node.js, a CPU, o swap e o disco do diretório de dados
- Restrinja o editor na porta 1880 ao IP administrativo e separe o que compete com o runtime
- Aumente só o recurso que saturou: RAM, CPU ou disco
Pré-requisitos
Antes de comparar planos, tenha acesso SSH com sudo em uma VPS com Ubuntu 24.04 LTS. Este artigo usa só essa versão: UFW e unidades systemd não se repetem igual em outra família de sistema. O Node-RED precisa estar em teste com os fluxos que vão para produção; sem essa carga, o número do plano continua chute. O runtime deve ser Node.js 22 LTS ou Node.js 24 LTS. Não assuma que o pacote nodejs do repositório padrão do Ubuntu 24.04 atende a essa linha: a 20 saiu de suporte em abril de 2026, e uma linha anterior não é base nova para esta escolha. Anote o IP de quem administra o editor e, se houver dispositivos MQTT, a rede deles. Tenha o console do provedor à mão antes de mexer no firewall. Painel web, banco local e proxy reverso não são obrigatórios para dimensionar.
- Ubuntu 24.04 LTS, usuário com sudo e console de recuperação do provedor
- Node.js 22 LTS ou 24 LTS já instalado, conferido com
node --version - Serviço de teste do Node-RED (no instalador Linux oficial o unit costuma se chamar
nodered) - IP administrativo de exemplo neste texto: 203.0.113.10; rede de dispositivos de exemplo: 198.51.100.0/24
- Lista do que vai dividir o host: fluxos, dashboard, broker, banco, scripts externos
Se node --version mostrar uma linha anterior à 22, troque o runtime antes de concluir que a VPS é pequena. O sintoma de Node antigo é incompatibilidade de nó, não falta de vCPU. Confirme também o nome real do serviço antes de ler log:
node --version
systemctl list-units --all --type=service 'nodered*'A primeira saída começa com v22. ou v24.. Na segunda, use --all para incluir unidades carregadas mesmo que inativas; o unit em execução aparece como active e running. Se a lista vier vazia, verifique também com systemctl list-unit-files 'nodered*' para checar unidades instaladas. Se o processo não estiver sob systemd com esse nome, ache o comando certo com ps antes de medir, em vez de subir o plano.
O que entra na conta da automação
O desperdício aparece quando a VPS é escolhida pelo número de sensores ou de visitas, e não pelo que os fluxos fazem de fato. Cada fluxo é um caminho de mensagens. Um inject curto, repetido em dezenas de fluxos, gera carga contínua mesmo com o editor fechado. Nó de função que guarda histórico em contexto de fluxo ou contexto global segura objeto na memória do Node.js; esse contexto permanece enquanto o runtime estiver ativo e só é removido quando o fluxo ou nó correspondente é excluído, quando o código o apaga explicitamente ou quando o processo reinicia — um deploy simples pode não apagar o contexto global nem o de fluxo. Nó que dispara script externo cria processo filho: esse RSS não está só dentro do node. Broker, banco e dashboard no mesmo host disputam RAM e tempo de CPU com a automação.
VPS não entrega GPIO, serial nem rádio no mesmo barramento. Fluxo que exige hardware físico ligado na máquina não cabe aqui, e mais núcleo não cria essa porta. A região do servidor pesa mais do que um vCPU extra quando os dispositivos estão longe: atraso de rede não se corrige com plano maior. Não há milissegundo "normal" para prometer; o que importa é se o atraso cabe no seu fluxo.
O hábito de medir processo e auxiliares é o mesmo de Como escolher VPS para uma API Node.js, mas o perfil muda. Lá o peso costuma ser requisição HTTP e banco. Aqui o peso é taxa de mensagem, contexto em memória e quem mais divide o host. Não copie o tamanho de uma API para esta automação. Hospedagem de site compartilhada, em geral, não mantém um processo Node contínuo na porta 1880; por isso a escolha recai em VPS, não em um plano de páginas.
Antes de contratar, anote quatro itens: quantos fluxos ficam ativos de verdade, se o dashboard permanece aberto, se o MQTT é local e se existe outro serviço pesado. Sem essa lista, qualquer upgrade é chute. Um fluxo simples, sem dashboard pesado e sem banco local grande, cabe em VPS modesta, com margem para o sistema. Vários clientes no dashboard, ou muitos nós com contexto, mudam a conta. Meça a carga real antes de tratar o plano atual como insuficiente ou como folgado demais.
Medir o processo antes de subir o plano
O processo Node.js é a unidade que decide RAM e CPU, não o rótulo do plano. Rode a automação com o intervalo real dos injects por alguns dias. Um teste de um minuto, ou um inject a cada milissegundo, mente para os dois lados. Leia memória, swap, RSS, carga e o journal. A coluna available do free é a folga para novo processo. Swap em zero não prova folga; swap subindo o tempo todo prova aperto de RAM.
free -h
nproc
uptime
pid=$(systemctl show -p MainPID --value nodered)
[ "$pid" != "0" ] && ps -p "$pid" -o pid,rss,pcpu,pmem,args
systemctl is-active noderedO formato do free -h traz as colunas total, used, free, shared, buff/cache e available. Os números mudam com a carga; o locale pode trocar o separador decimal. Obtenha o PID pelo serviço antes de consultar o processo; confirme que $pid não é zero antes de continuar. RSS vem em kilobytes; a coluna COMMAND mostra os argumentos e deve citar o diretório de dados do Node-RED. Se o unit usar o wrapper node-red como entrada, use pgrep -af 'node-red|red.js' para localizar o PID alternativamente. systemctl is-active nodered imprime active quando o unit está em execução. inactive ou failed pede log, não plano maior.
Compare o load average de 1 minuto do uptime com a saída do nproc. Load acima do número de vCPUs pode indicar saturação de CPU, mas também pode refletir espera de I/O; para confirmar saturação de CPU, correlacione com a utilização real usando top, vmstat 1 ou pidstat -p $pid 1. Carga baixa com atraso pode indicar event loop bloqueado por código síncrono pesado, ou latência acumulada em operações assíncronas de rede: código síncrono em nó de função ocupa o event loop e atrasa todas as mensagens; operações de rede assíncronas aumentam latência sem ocupar CPU, mas podem acumular filas internas. Investigue com métricas de event-loop delay, latência do broker e tamanho das filas. Mais núcleo não destrava o loop principal.
ss -lnt 'sport = :1880'
sudo journalctl -u nodered -n 30 --no-pager
sudo journalctl _TRANSPORT=kernel --since "7 days ago" --no-pager --grep 'Out of memory|Killed process'No ss, a linha relevante é LISTEN na porta 1880. Endereço 0.0.0.0:1880, [::]:1880 ou *:1880 significa editor alcançável em todas as interfaces. 127.0.0.1:1880 ou [::1]:1880 significa só local. O terceiro comando consulta mensagens do kernel sem limitar ao boot atual, cobrindo reinícios anteriores dos últimos 7 dias. Se não houve morte por memória, o journal responde -- No entries --. Se houve, a linha cita processo morto: isso é falta de RAM ou vazamento de contexto, não "instabilidade da VPS".
O editor não precisa ficar aberto na internet para os fluxos rodarem. Libere SSH e a porta 1880 só do IP de administração. Se o seu acesso for IPv6, inclua esse endereço também; a regra abaixo é IPv4.
Atenção: habilitar o UFW sem liberar o SSH do seu IP derruba a sessão. Troque 203.0.113.10 pelo IP real antes do enable. Não desative o firewall para "resolver" acesso.
sudo ufw status
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow from 203.0.113.10 to any port 1880 proto tcp
sudo ufw enable
sudo ufw statusCom o firewall ainda desligado, ufw status mostra Status: inactive e não lista regras. O enable pede confirmação; responda sim só depois das duas regras allow. No status ativo, as linhas relevantes são 22/tcp e 1880/tcp com origem 203.0.113.10. Não abra a porta 22 para qualquer origem se a regra de administração é por IP. A regra da porta 1880 bloqueia todo o acesso nessa porta para origens não listadas, incluindo clientes do dashboard: se somente o administrador acessará qualquer conteúdo da porta 1880, mantenha a regra como está; se o dashboard precisar ser acessado por outras redes, use autenticação e um proxy reverso com controle de acesso por caminho, inclua as redes dos clientes em regras adicionais ou desative o editor quando aplicável.
Dashboard, MQTT e serviços vizinhos
Dashboard e MQTT mudam o consumo, mas não do mesmo jeito. O dashboard segura conexão e atualiza widget. Mais clientes e mais mensagens por segundo sobem CPU e RAM, mesmo com os fluxos "leves" no papel. Travamento do dashboard é sintoma a investigar: verifique memória disponível, RSS crescente e eventos de OOM antes de atribuir à RAM — saturação de CPU, event loop bloqueado ou excesso de atualizações também causam lentidão na interface. O MQTT em si é leve. Volume alto de tópicos, retenção e um broker no mesmo servidor é que competem com o Node-RED. Separe o que é fluxo, o que é broker e o que é interface antes de aumentar o plano inteiro.
Se os dispositivos publicam num broker de fora, esta VPS só precisa alcançar esse broker. Não compre RAM local para um serviço que não está aqui. Se o broker for local, a porta dos dispositivos (em geral 1883, ou 8883 com TLS) tem de alcançar a rede deles. Isso não justifica abrir a porta 1880. Exemplo para uma rede de dispositivos, não para a internet inteira:
sudo ufw allow from 198.51.100.0/24 to any port 1883 proto tcp
sudo ufw statusA linha nova deve mostrar 1883/tcp vindo de 198.51.100.0/24. Ajuste a rede. Se usar TLS no broker, instale no servidor somente a chave privada do próprio servidor, o certificado correspondente e os certificados públicos da cadeia de confiança. Mantenha a chave privada da CA fora da VPS, preferencialmente offline ou em infraestrutura de emissão protegida — comprometer esta VPS não deve permitir emitir novos certificados confiáveis pela CA. Restrinja as permissões da chave do servidor e não use chmod 777 em certificado nem em flows_cred.json.
Banco de série temporal, Grafana ou outro painel no mesmo host deixam de ser "só Node-RED". Meça cada processo com ps antes de culpar os fluxos. Proxy reverso na frente do editor é decisão à parte, quando você precisar de HTTPS e de um nome como seudominio.com.br. A comparação de servidores web está em Apache, Nginx ou LiteSpeed: como escolher para seu VPS Linux. Não instale um servidor web só para "completar" a VPS: ele também gasta RAM.
Node-RED em Docker na VPS isola a versão do Node.js e permite volume para os dados, mas o container não reduz o consumo dos fluxos. Os processos do container, o daemon/runtime e as páginas efetivamente usadas ainda consomem RAM; a imagem também ocupa disco. No limite, o host fica mais apertado, não mais folgado. Use container se a operação exigir imagem fixa e volume; não use só para economizar recurso. Se já estiver em Docker, o RSS do processo Node ajuda a diagnosticar o processo, mas para dimensionar o container considere também o consumo do cgroup com docker stats e métricas de memory.current/memory.events, além da memória total do host.
Disco, logs e o diretório de dados
O arquivo de fluxos, flows.json, costuma ser pequeno. O que enche disco é outra coisa: nós instalados no diretório do usuário, contexto em arquivo, log do journal e, se o broker for local, retenção de mensagem. Disco cheio impede gravar deploy e não se resolve com mais CPU. Descubra o usuário do serviço antes de apontar caminho. O instalador oficial guarda os dados no home desse usuário, em .node-red. Outra instalação pode usar outro diretório: leia o unit, não invente o caminho.
systemctl show nodered -p User --value
df -h /
sudo du -sh /home/USUARIO/.node-red
sudo journalctl --disk-usageTroque USUARIO pela saída do primeiro comando. Se a saída vier vazia, o serviço roda como root e o userDir é /root/.node-red — confirme com systemctl cat nodered para checar o ExecStart e o WorkingDirectory. df -h / mostra Use% da raiz. journalctl --disk-usage informa quanto os journals ocupam no sistema de arquivos. Suba de plano de disco se o uso cresce com log ou com contexto em arquivo, mesmo com CPU folgada.
Contexto em memória alivia disco e usa RAM. Contexto em arquivo adiciona persistência e I/O de disco, mas o armazenamento localfilesystem padrão do Node-RED mantém cache em memória e grava periodicamente; mover contexto para arquivo não garante redução de RAM. Confirme o comportamento com a configuração do contextStorage e por medição. Se o log avisar que o segredo de credenciais não está definido, trate isso como configuração: sem credentialSecret fixo no settings.js, o Node-RED gera uma chave e a persiste em .config.runtime.json no userDir — ela sobrevive a reinícios normais, mas se esse arquivo for perdido em restore parcial ou migração de host, o flows_cred.json deixa de ser decifrável e o sintoma parece "perda de fluxo". Configure um credentialSecret estável e inclua o .config.runtime.json no backup.
Atenção: o pacote abaixo inclui flows_cred.json. É segredo. Não deixe o arquivo legível por outros usuários e não publique em diretório web.
sudo sh -c 'umask 077; tar -C /home/USUARIO -czf /root/nodered-userdir.tgz .node-red'
sudo ls -l /root/nodered-userdir.tgzConfirme que o ls -l mostra permissão -rw------- (modo 0600) no arquivo gerado. Faça esse backup antes de testar nós novos ou antes de um resize que exija reinício. Confirme no painel do provedor se aumentar RAM ou disco reinicia a VPS. Os fluxos voltam se o disco do userDir persistir. Não apague flows.json para "liberar espaço".
Log antigo pode ser reduzido, mas a redução apaga histórico de diagnóstico. Só faça isso depois de copiar o que precisar e de confirmar que o disco, e não a RAM, é o limite.
Atenção: o comando a seguir remove journals arquivados tentando reduzir o conjunto até o teto indicado. Journals ativos não são removidos, portanto o uso total pode continuar acima de 200 MB. As linhas removidas não são recuperadas.
sudo journalctl --vacuum-size=200MDecidir CPU, RAM ou separação de serviço
Aumente RAM quando houver baixa memória disponível, paginação ativa e recorrente confirmada por free ou vmstat, crescimento sustentado de RSS ou eventos de OOM. Swap contendo dados não indica pressão atual de memória por si só, pois o Linux pode manter páginas frias no swap mesmo após a RAM voltar a ficar disponível. Travamento do dashboard é sintoma a investigar: verifique CPU, event loop, rede e navegador antes de concluir que a causa é RAM. Aumente CPU se os fluxos atrasam na taxa normal de mensagens e o Node.js permanece ocupado por longos períodos. Disco cheio por log ou por contexto em arquivo é upgrade à parte, independente de CPU. Pagar núcleo ocioso não estabiliza o Node-RED. Se o ps mostra o processo folgado e outro processo no topo, o upgrade do plano inteiro só mascara o vizinho errado.
Comece com um plano pequeno, deixe a automação real rodar alguns dias e suba só o recurso que saturou. Memória que cresce sem parar, dia após dia, com a mesma carga, não é "cache saudável": é contexto, vazamento de nó ou cliente de dashboard acumulado. Reiniciar o serviço esconde o problema por horas e não justifica um plano maior até você saber o que cresce.
Separe o broker quando a retenção ou a taxa de tópicos disputar CPU com os fluxos e o ps mostrar os dois no limite. Separe o dashboard se muitos clientes só observam, e o runtime em si cabe no plano: às vezes o alívio é menos widget e menos conexão, não o dobro de vCPU. Não mova o editor para a internet aberta para "testar se a VPS aguenta". Scanner na porta 1880 gasta CPU e não representa os seus dispositivos.
Servidor dedicado entra na conversa só quando um processo contínuo, já medido, não cabe no maior VPS que você aceita operar, ou quando o vizinho (banco grande, broker com retenção longa) precisa de disco e RAM que você não quer misturar. Para um conjunto pequeno de fluxos, dedicado é desperdício do outro lado. Reavalie depois de cada mudança de nó: um único nó de função com laço pesado altera a conta mais do que o nome do plano.
Problemas comuns e como resolver
Sintoma: o Node-RED para e os fluxos não disparam
Causa: o kernel encerrou o processo por falta de memória, em geral depois de pico de dashboard ou de contexto em RAM. Também pode ser unit em failed por erro de configuração, que não se cura com mais CPU.
Solução: rode systemctl is-active nodered e o journalctl _TRANSPORT=kernel indicado acima. Se houver processo morto, reduza contexto em memória ou clientes do dashboard e só então aumente RAM. Se o journal do serviço mostrar segredo de credencial ou erro de nó, corrija o userDir. Não desative o firewall e não apague o unit para "subir de qualquer jeito".
Sintoma: mensagens atrasam e a CPU da VPS parece ociosa
Causa: o runtime principal é um event loop. Código síncrono pesado em nó de função bloqueia o event loop e segura a fila. Operações de rede assíncronas, como conexão a broker remoto, aumentam latência sem ocupar CPU, mas podem acumular filas internas. Ambos os casos resultam em mensagens atrasadas com load average baixo. Mais vCPU fica parado.
Solução: compare uptime com nproc e o %CPU do processo no ps. Para código síncrono, enxugue o nó que bloqueia e confira o intervalo real dos injects. Para latência de rede, investigue métricas de event-loop delay e latência do broker. Aumente CPU só se o processo permanecer efetivamente ocupado na taxa normal de mensagens. Trocar a região da VPS ajuda atraso de rede; trocar só o número de núcleos, não.
Sintoma: o deploy falha e o disco da raiz chega a 100%
Causa: journal, contexto em arquivo, nós instalados ou retenção do broker local encheram o disco. O flows.json em si raramente é o vilão.
Solução: use df -h / e du no userDir. Faça backup do diretório antes de apagar qualquer coisa. Reduza journal só com journalctl --vacuum-size, ciente da perda de histórico e de que journals ativos não são removidos. Aumente disco se o crescimento for legítimo. Não rode chmod 777 no userDir e não delete flows.json nem flows_cred.json para abrir espaço.
Sintoma: o editor deixa de abrir depois do UFW
Causa: a regra da porta 1880 ou da 22 não usa o IP de onde você está agora, ou o acesso é IPv6 e só existe regra IPv4.
Solução: entre pelo console do provedor, rode sudo ufw status e inclua o IP correto nas portas 22 e 1880. Não use ufw disable como estado final. Confira com ss se o Node-RED ainda escuta na 1880 antes de culpar o firewall.
Perguntas frequentes
Quantos recursos uma VPS precisa para Node-RED sem desperdício?
Não existe um tamanho único: o consumo depende do número de fluxos, do broker MQTT, do dashboard e de nós que guardam contexto em memória. Comece com um plano pequeno, rode a automação real por alguns dias e suba CPU ou RAM só se o processo Node.js ficar limitado ou a memória crescer de forma contínua. Pagar por núcleos ociosos não deixa o Node-RED mais estável.
Node-RED funciona em uma VPS com pouca memória?
Um fluxo simples, sem dashboard pesado e sem banco local grande, costuma caber em uma VPS modesta com margem para o sistema e para o Node.js. Se vários clientes abrem o dashboard ao mesmo tempo ou se há muitos nós de função com contexto, a memória sobe rápido e o processo pode ser encerrado pelo sistema. Meça com a carga real antes de concluir que o plano atual basta.
Dashboard e MQTT aumentam o consumo do Node-RED?
Sim. O dashboard mantém conexões e atualiza widgets; quanto mais clientes e mais mensagens por segundo, maior o uso de CPU e RAM. O MQTT em si é leve, mas um volume alto de tópicos, retenção ou um broker no mesmo servidor compete com o Node-RED. Separe o que é fluxo, o que é broker e o que é interface antes de aumentar o plano inteiro.
Vale colocar só o Node-RED em Docker na VPS?
Docker ajuda a isolar a versão do Node.js e a persistir dados em volume, mas o container não reduz o consumo dos fluxos. Os processos do container, o daemon/runtime e as páginas efetivamente usadas ainda consomem RAM; a imagem também ocupa disco. No limite, o host fica mais apertado, não mais folgado. Use container se a operação exigir; não use só para "economizar" recurso.
Quando aumentar CPU ou RAM no Node-RED?
Aumente RAM quando houver baixa memória disponível, paginação ativa e recorrente, crescimento sustentado de RSS ou eventos de OOM. Swap com dados não confirma pressão atual de memória por si só, pois o Linux pode manter páginas frias no swap mesmo após a RAM voltar a ficar disponível. Travamento do dashboard pode ter outras causas — investigue CPU, event loop, rede e navegador antes de atribuir à RAM. Aumente CPU se os fluxos atrasam com a taxa normal de mensagens e o Node.js fica ocupado por longos períodos. Disco cheio por logs ou contexto em arquivo é outro motivo de upgrade, independente de CPU.
Conclusão
Escolher VPS para esta automação é uma leitura de processo, não um palpite por quantidade de dispositivos. O Ubuntu 24.04 LTS dá o terreno de medida; o plano certo é o que cobre o RSS, a CPU realmente ocupada e o disco do userDir, com o editor fechado para o resto da internet.
- Deixe os fluxos reais rodarem alguns dias num plano pequeno e anote RSS, swap, load e disco antes de qualquer upgrade.
- Restrinja as portas 22 e 1880 ao IP de administração e não abra o editor só porque o MQTT precisa ser alcançado.
- Suba RAM, CPU ou disco só com o sintoma correspondente; se o vizinho for o broker ou o dashboard, separe esse serviço em vez de dobrar o plano inteiro.
Leia também
- Como Instalar e Configurar o Rsync para Sincronização e Backup Seguro no VPS Linux
- Checklist para Configurar e Testar o Limite de Espaço em Disco por Usuário no VPS Linux e Servidor Dedicado
- Guia para Configurar Backup Remoto com Rclone em Servidor Dedicado e VPS Linux
Precisa de ajuda com VPS para Node-RED?
Um plano enxuto, medido com a sua automação, evita pagar núcleo parado. Compare opções de VPS para processo contínuo e fique com o recurso que a medição pedir, não com o maior da tabela.
