Como instalar Node-RED com Docker em VPS: SSL, domínio e backup

Para instalar Node-RED com Docker em uma VPS, você precisa de acesso SSH administrativo, uma VPS Linux, domínio com DNS sob seu controle, Docker com Compose disponível, portas 80 e 443 liberadas e um local externo para guardar segredos e cópias. O processo abaixo é um checklist baseado na documentação oficial; o Runzos não executou esta stack. O tempo não foi medido e o custo varia conforme VPS, domínio e armazenamento externo.

Node-RED ajuda a desenhar integrações entre HTTP, webhooks, MQTT, APIs e dispositivos. Não é, porém, um “n8n barato”. Ele entrega liberdade técnica para quem aceita operar uma camada mínima de infraestrutura.

Este guia não substitui uma validação no seu ambiente. Adapte domínio, versão e segredos antes de usar em produção. Não use os exemplos para publicar senha, token, IP ou credentialSecret.

A ideia central aqui é Backup de Verdade. Uma cópia só merece esse nome quando você consegue restaurá-la e validar fluxos e credenciais. Um volume no mesmo servidor protege contra recriação do container. Não protege contra perda, erro ou indisponibilidade do host.

Para quem Node-RED faz sentido em 2026

O projeto Node-RED se apresenta como uma ferramenta low-code para aplicações orientadas a eventos. O repositório oficial é público, usa licença Apache-2.0 e é mantido por Nick O’Leary e Dave Conway-Jones. Na prática, ele faz mais sentido quando o fluxo mistura APIs, webhooks, MQTT, lógica própria ou dispositivos.

Você monta um fluxo visual, mas continua decidindo como cada evento entra, é validado, falha e sai. Isso é uma vantagem quando a automação precisa conversar com sistemas técnicos. Também pode ser uma desvantagem quando a equipe quer conectores SaaS prontos e não tem alguém para cuidar da VPS.

A comparação não é sobre uma ferramenta vencer sempre. É sobre onde você quer pagar a complexidade. SaaS concentra parte dela no fornecedor. Self-hosting deixa a arquitetura mais visível e transferível, mas exige rotina. Para uma comparação publicada entre plataformas de automação, veja n8n vs Make.

O custo real da autonomia em uma VPS

Node-RED não cobra licença. Isso não torna a operação gratuita. A VPS, o domínio, o proxy, a cópia externa, as atualizações e o tempo para investigar uma falha entram na conta.

Não existe requisito oficial universal de CPU e RAM para Node-RED. O consumo varia com nós instalados, frequência dos fluxos, tamanho dos payloads, banco, dashboards e processos externos. Como ponto de partida editorial, 1 vCPU e 1 GB de RAM servem para um experimento leve e isolado. Quando há proxy, fluxos contínuos ou outros serviços, 2 vCPU e 2 a 4 GB dão mais margem para observar o consumo antes de escalar.

Essa faixa não é garantia de desempenho. Monitore CPU, memória, disco e logs após colocar os primeiros fluxos em uso. Uma VPS única também continua sendo um ponto único de falha.

Quando você já decidiu operar essa camada, a VPS da Hostinger para n8n e automações é uma rota comercial do Runzos. O preço, a renovação e qualquer cupom dependem da condição vigente. Confira a página da oferta antes de contratar.

Pré-requisitos e arquitetura do tutorial

Separe os itens antes de criar arquivos. Você precisa de uma VPS Linux atualizada, acesso SSH com permissão administrativa, Docker e o plugin Compose instalados, domínio apontável para o IP público, firewall para 80 e 443, e um cofre ou gerenciador de senhas para o credentialSecret.

Também confira se nada usa 80 ou 443 na VPS. O exemplo usa Caddy como proxy reverso. Ele recebe HTTP e HTTPS no host. Node-RED fica somente na rede interna do Docker, sem publicar 1880.

A arquitetura esperada é esta:

1. O DNS do domínio aponta para o IP público da VPS.
2. Caddy recebe conexões nas portas 80 e 443.
3. Caddy encaminha HTTPS para node-red:1880 pela rede interna.
4. Node-RED mantém fluxos e configurações no volume montado em /data.
5. Uma cópia externa de /data entra na rotina de recuperação.

A documentação de segurança do Node-RED informa que o editor não é protegido por padrão. Quem alcança o IP pode acessar o editor e fazer deploy. Portanto, 1880 é porta interna da aplicação, não uma página pública.

Conforme a documentação de HTTPS automático do Caddy, o Caddy pode provisionar e renovar certificados, além de redirecionar HTTP para HTTPS, quando hostname, DNS e portas necessários estão corretos. Ele não corrige DNS apontado para IP errado nem firewall bloqueando as portas.

Instalação: Node-RED, Docker, domínio e HTTPS

Os passos abaixo são executáveis, mas não foram executados pelo Runzos. Faça cada validação antes de avançar. O tempo de execução não foi medido.

1. Prepare a VPS e a pasta da stack

Entre por SSH, confirme que Docker e Compose respondem e crie uma pasta exclusiva para os arquivos. Libere 80 e 443 no firewall e no painel do provedor, se ele tiver firewall próprio.

docker --version
docker compose version
sudo mkdir -p /opt/node-red
sudo chown "$USER":"$USER" /opt/node-red
cd /opt/node-red

Você deve ver versões do Docker e do Compose. O diretório /opt/node-red deve existir e ser gravável pelo usuário usado na instalação. Se docker compose version falhar, instale ou habilite o plugin Compose antes de continuar.

2. Crie o compose.yaml

No diretório criado, salve o arquivo abaixo como compose.yaml. O serviço node-red usa a imagem oficial e persiste /data. Só Caddy publica portas no host.

services:
  node-red:
    image: nodered/node-red:latest
    restart: unless-stopped
    volumes:
      - node_red_data:/data
    networks:
      - internal

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - internal

volumes:
  node_red_data:
  caddy_data:
  caddy_config:

networks:
  internal:

O resultado esperado é um arquivo com dois serviços, três volumes e uma rede. Repare no que não aparece: node-red não possui ports: e não existe 1880:1880.

3. Crie o Caddyfile

No mesmo diretório, crie um arquivo chamado Caddyfile. Troque o domínio de exemplo pelo hostname que já aponta para sua VPS.

automacao.seudominio.com.br {
  reverse_proxy node-red:1880
}

O resultado esperado é um proxy que conhece o serviço interno pelo nome node-red. Não use um IP privado fixo do container: o nome do serviço é resolvido pela rede do Compose.

4. Valide os arquivos e suba os serviços

Valide o Compose antes de baixar imagens. Depois, inicie a stack em segundo plano e confira o estado dos containers.

docker compose config
docker compose up -d
docker compose ps

docker compose config deve retornar a configuração consolidada sem erro. Após a subida, docker compose ps deve listar node-red e caddy em execução. Se algum serviço não estiver ativo, não siga para o domínio: consulte os logs com docker compose logs --tail=100 caddy ou docker compose logs --tail=100 node-red.

5. Acesse pelo domínio, não pela porta 1880

Abra https://seu-dominio no navegador. O resultado esperado é o editor Node-RED servido por HTTPS. Teste em janela anônima para evitar sessão e cache anteriores.

Não trate a abertura da tela como configuração final. O editor ainda precisa de autenticação. A porta 1880 deve continuar interna; o navegador não precisa receber uma URL com :1880.

6. Faça o hardening antes de criar fluxos reais

A documentação Docker do Node-RED usa /data para guardar mudanças e fluxos. Ela também orienta definir um credentialSecret estável. Se a chave gerada pelo sistema for perdida, as credenciais não poderão ser recuperadas e precisarão ser informadas novamente.

Edite o settings.js persistido em /data seguindo a documentação de segurança do Node-RED. Defina um credentialSecret novo e guarde esse valor fora da VPS e do repositório. Em seguida, configure adminAuth para proteger o editor e a Admin API. Reinicie o serviço depois de salvar a configuração.

Avalie httpNodeAuth separadamente para rotas criadas por HTTP In nodes. adminAuth protege editor e Admin API. httpNodeAuth usa autenticação básica para rotas HTTP expostas pelos HTTP In nodes. Um não substitui o outro.

Não cole hash de senha, token, segredo ou IP real em commits, prints ou chats. HTTPS, proxy e rede interna reduzem exposição, mas não definem a autenticação de cada webhook público.

Como saber se funcionou

Faça estas verificações no servidor e fora dele. Elas confirmam a configuração, não substituem teste dos fluxos de negócio.

1. Compose válido: execute docker compose config. O comando deve terminar sem erro e a saída não deve mostrar 1880:1880 no serviço node-red.
2. Serviços ativos: execute docker compose ps. node-red e caddy devem aparecer em execução. Se não aparecerem, use docker compose logs --tail=100 NOME_DO_SERVICO antes de alterar arquivos.
3. HTTPS no domínio: de uma máquina com acesso à internet, execute curl -I https://seu-dominio. Espere uma resposta HTTP do domínio por HTTPS. O certificado deve corresponder ao hostname acessado.
4. Porta 1880 fora do host: na VPS, execute sudo ss -ltnp | grep ':1880'. Em uma stack como a deste Compose, não deve haver processo ouvindo 1880 no host. De uma rede externa, uma tentativa de curl http://IP_PUBLICO:1880 não deve abrir o editor.
5. Editor protegido: abra o domínio em janela anônima depois de configurar adminAuth. Espere o desafio de autenticação antes do acesso ao editor.

Registre os resultados e a versão das imagens antes de colocar um fluxo crítico em produção. O Runzos não executou nem mediu esses testes para este artigo.

Problemas comuns

O domínio não abre ou aponta para outro lugar

Confirme no provedor de DNS que o registro do hostname aponta para o IP público atual da VPS. Aguarde a propagação do DNS antes de pedir um certificado. Também confirme que o firewall do provedor e o firewall da VPS permitem 80 e 443.

Caddy não inicia porque 80 ou 443 já estão ocupadas

Use sudo ss -ltnp para identificar o processo que escuta nas portas. Outro proxy, painel ou servidor web pode estar usando a porta. Pare ou reconfigure o serviço conflitante antes de subir Caddy. Não publique portas alternativas como substituto permanente sem revisar DNS, proxy e a arquitetura.

O certificado não é emitido ou renovado

Revise o hostname no Caddyfile, o apontamento DNS e a conectividade pública nas portas necessárias. Consulte docker compose logs --tail=100 caddy para a mensagem específica. O HTTPS automático do Caddy depende dessas condições; não é uma garantia se o domínio ainda não resolve corretamente.

As credenciais pararam de funcionar após recriar ou restaurar

Verifique se o credentialSecret original foi preservado no cofre de segredos. Sem essa chave, o Node-RED não recupera as credenciais existentes; elas precisam ser informadas outra vez. Não tente substituir o segredo sem entender o impacto nos fluxos e faça o procedimento primeiro em ambiente separado.

Backup, atualização e restore: o que mantém a automação viva

O volume persistente evita que a recriação normal do container apague /data. A imagem oficial pode ser atualizada removendo e recriando o container sem perder os dados desse diretório. Ainda assim, copie os dados antes de atualizar.

É aqui que entra o Backup de Verdade: não basta criar um arquivo no mesmo disco da VPS. Você precisa de uma cópia externa, retenção definida e um restore validado em ambiente controlado.

Uma sequência prudente de atualização é criar cópia externa, registrar a versão em uso, atualizar a imagem, recriar o serviço, abrir o editor, testar um fluxo importante e revisar logs. Se algo falhar, pare e restaure a cópia em ambiente separado antes de concluir que o backup funciona.

A política restart: unless-stopped faz o Docker reiniciar o serviço salvo parada ou remoção explícita. Ela não equivale a monitoramento, alta disponibilidade ou backup. Para entender a diferença entre volume e cópia recuperável, consulte a documentação de volumes do Docker.

Projects do Node-RED podem usar Git para versionar arquivos de fluxos e colaborar, conforme a documentação de Projects do Node-RED. Git é útil para portabilidade. Não é uma cópia automática de volume, chave, DNS ou certificado.

Node-RED vs n8n vs Make/Zapier: escolha pelo trabalho que você aceita

Node-RED favorece fluxos técnicos e orientados a eventos. n8n é uma alternativa self-hosted frequente para workflows de automação. Make e Zapier são SaaS gerenciados, não produtos para auto-hospedar.

A diferença prática está no trabalho de operação. Em Node-RED e n8n self-hosted, alguém precisa responder por VPS, atualização, proxy, credenciais e cópias. Em SaaS, parte desse trabalho fica no serviço, em troca de menos controle do host e das condições do plano.

Não escolha Node-RED apenas porque a licença é aberta. Escolha quando a natureza do fluxo justifica manter a infraestrutura. Se o principal objetivo é publicar integrações SaaS sem administrar servidor, a opção gerenciada pode ser mais honesta e mais barata no custo total.

FAQ sobre Node-RED com Docker em VPS

O Node-RED pode rodar em Docker?

Sim. A imagem oficial é nodered/node-red. O guia oficial monta um volume em /data para persistir mudanças e fluxos entre recriações do container.

Onde ficam os fluxos e as credenciais?

O diretório /data é o local persistido pela imagem oficial. Credenciais exigem um credentialSecret estável. Se a chave gerada pelo sistema for perdida, as credenciais não poderão ser recuperadas.

É seguro expor a porta 1880 na internet?

Não como padrão de produção. Por padrão, quem alcança o IP pode acessar o editor e fazer deploy. Use a porta apenas em rede controlada e coloque um proxy HTTPS na frente para acesso público.

Como configurar SSL com domínio?

Aponte o DNS para a VPS, libere as portas necessárias e deixe um proxy reverso receber o domínio. Caddy pode provisionar e renovar TLS automaticamente quando hostname, DNS e conectividade atendem às condições da documentação.

Como faço backup e restauração do Node-RED?

Preserve /data, o credentialSecret, os arquivos de infraestrutura e o acesso ao DNS. Mantenha uma cópia externa e teste a restauração em ambiente separado antes de depender dela.

Quanta RAM preciso para Node-RED em uma VPS?

Não há requisito oficial universal. Como ponto editorial, 1 GB de RAM atende um experimento leve e isolado; com proxy, fluxos contínuos ou outros serviços, 2 a 4 GB dão mais margem. Monitore o consumo real antes de escalar.

Node-RED ou n8n: qual é melhor?

Depende do fluxo e da operação. Node-RED combina com eventos, MQTT, HTTP e lógica técnica. n8n é uma alternativa forte para automação de workflows. Ambos exigem infraestrutura quando são auto-hospedados.

Veredito: VPS para automação exige uma rotina recuperável

Node-RED com Docker é uma base direta para automações técnicas em VPS. A instalação não é a parte difícil. O que separa uma demonstração de uma operação sustentável é proteger o editor, deixar a porta 1880 fora da internet, preservar /data, guardar o segredo de credenciais e testar restauração.

Se você aceita operar essa autonomia, comece com uma VPS que comporte a stack e trate backup como requisito desde o primeiro fluxo. Para comparar uma alternativa brasileira voltada a VPS e automações, veja a oferta de VPS da Servla para n8n. Preço, capacidade, suporte, renovação, backup e qualquer cupom devem ser conferidos nas condições vigentes da oferta antes de contratar.