Como deixar o n8n rodando 24 horas sem depender do seu PC ligado

Fala aí, beleza? Seu fluxo não parou de funcionar de madrugada: você que desligou o PC 😅

É o roteiro clássico de quem instalou o n8n no Windows pra testar: monta o workflow, roda, funciona lindo, fecha o terminal e vai dormir

aí o trigger que era pra disparar às 3 da manhã simplesmente não dispara

A regra é dura e simples: o n8n só executa em produção enquanto a instância dele estiver rodando

Automação que depende da sua máquina acordada não é automação, é demonstração

Esse post é a continuação natural do guia de instalação: sair do local e ir pro servidor mantendo o n8n 24 horas no ar, sem perder workflow nem credencial no caminho

O que a instalação local ensina (e onde ela trava)

No vídeo abaixo eu mostro a instalação local pelo npm, com instalação global e depois o comando de start

Quando rodei ali, o serviço subiu um servidor local na própria máquina e o editor ficou acessível por um endereço local que eu abri direto do terminal

No primeiro start o n8n cria um banco local pra guardar as configurações e passa pela tela de cadastro do dono da instância

Esse e-mail do cadastro é só o seu login naquela instalação, ele não é o registro de licença da Community Edition (é outra coisa, e eu explico mais pra frente)

Eu montei um workflow bem simples, gatilho manual e um nó de edição de campos com um texto de teste, rodei e o resultado saiu com sucesso

Massa pra aprender, ótimo pra testar, ótimo pra encadear nós e entender o comportamento de cada um, inclusive quando você começa a montar automações com agentes de IA dentro do fluxo

Detalhes do ambiente local que vale saber antes:

• A instalação via npm pede Node.js entre 20.19 e 24.x, inclusive
• Dá pra rodar sem instalar nada global usando npx n8n, e o editor abre em http://localhost:5678
• Depois de instalar, abra um terminal novo: às vezes o comando não é reconhecido de primeira
• Pra atualizar, pare o n8n antes e rode o update pelo npm, depois inicie de novo
• Existe versão de ponta pelo npm, mas ela não é estável e não deveria ir pra produção
• O modo tunnel serve pra desenvolvimento e testes locais (ele usa cloudflared e exige Docker instalado, e a implementação pode mudar entre versões); em produção o certo é a Production webhook URL

E onde exatamente ela trava?

No momento em que o trigger precisa acontecer sem ninguém por perto

Enquanto você aperta o play, tá tudo certo

Quando o fluxo é agendado, ou espera um webhook chegar, ou precisa rodar de hora em hora, o processo tem que estar ligado o tempo todo

E olha que a lista de condições nem é grande: o workflow precisa estar salvo e publicado, com o toggle Active ligado, e a instância do n8n precisa estar rodando na hora em que a condição do trigger acontece

As três primeiras você resolve no editor em dez segundos

a última é justamente a que o PC local não te dá

E aí já dá pra ver que esse ambiente local não é o que você entrega pra um cliente

Um fluxo que salva tarefas quando você integra o n8n com o Notion só faz sentido se ele estiver de pé às 2 da tarde de uma terça em que seu notebook tá fechado

PC local, VPS ou n8n Cloud: qual sai na frente para rodar 24 horas

São três caminhos e cada um cobra um preço diferente (nem sempre em dinheiro)

Opção	Fica ligado sem você?	Custo	Manutenção	Execuções
PC local (npm ou Docker na sua máquina)	Não, só enquanto o processo estiver rodando	Community Edition self-hosted: gratuita por tempo indeterminado	Sua, e você ainda depende da máquina ligada	Sem cota contratada
VPS com Docker (self-hosted)	Sim, se o container voltar sozinho depois de reboot	O n8n continua gratuito; o custo é da hospedagem, não do n8n	Sua: update, backup, chave de criptografia, domínio e proxy	Sem cota contratada
n8n Cloud (plano Starter)	Sim	20 euros por mês no pagamento anual, ou 24 euros por mês no mensal	Do n8n, você só usa	2.500 execuções por mês, com usuários e workflows ilimitados

Então o n8n é gratuito ou não?

Essa é a dúvida que mais aparece, e a resposta honesta é: depende de qual n8n você tá falando

A Community Edition self-hosted é gratuita indefinidamente, rodando na sua própria infraestrutura

O projeto é distribuído sob a Sustainable Use License, uma licença fair-code que permite uso, modificação e redistribuição gratuitos com limitações: o uso é permitido pra fins internos do próprio negócio, uso pessoal ou não comercial (a restrição a serviços de consultoria e suporte foi removida)

Se quiser conferir o texto na fonte, ele tá na documentação da licença

Tem também o registro do e-mail na Community Edition, que é gratuito e libera recursos extras: folders, debug in editor e custom execution data

E se liga que esse registro não é o mesmo e-mail do cadastro que você faz no primeiro start: aquele é só o login da instância, esse aqui é o que destrava os recursos extras

Já o Cloud tem teste gratuito de 14 dias com recursos do plano Pro e limite de 1.000 execuções, com o mesmo poder computacional do Starter, e ele expira sozinho sem cobrança

O que ter em mãos antes de migrar para a VPS

Antes de sair rodando comando, junte essas coisas:

• Acesso a um servidor com Docker instalado e funcionando
• A instância local ainda de pé, porque é dela que você vai exportar tudo
• Os workflows salvos, sem alteração pendente no editor
• A noção da chave de criptografia: o n8n gera uma chave aleatória no primeiro start e salva na pasta ~/.n8n, e é ela que decifra as credenciais gravadas no banco
• Um domínio (e proxy reverso na frente) se você usa webhooks, porque o endereço local não serve pra serviço externo nenhum

O ponto da chave é o que mais pega gente desprevenida

As credenciais viajam junto no export, mas elas viajam criptografadas

Se a chave do destino for outra, você vai ver a credencial lá bonitinha na lista e ela não vai abrir na hora da execução

Tome cuidado com isso antes de destruir o ambiente local 🙂

Como migrar o n8n do seu PC para a VPS sem perder os workflows

1. Exporte os workflows (e as credenciais)

Pra poucos fluxos, o caminho é a própria interface: nos três pontos no canto superior direito do editor você tem Download (baixa o workflow atual como JSON), Import from File e Import from URL, e ainda dá pra copiar e colar nós com Ctrl+C / Ctrl+V

Pra levar tudo de uma vez, a CLI resolve melhor:

n8n export:workflow --backup --output=backup/workflows

A flag --backup é um atalho: ela equivale a --all --pretty --separate, e o --output define onde os arquivos são salvos

O erro comum deste passo: baixar só o JSON do workflow pelo menu e achar que as credenciais foram junto (o Download baixa o workflow atual, e só)

2. Guarde a chave de criptografia e planeje o N8N_ENCRYPTION_KEY do servidor

A chave criada no primeiro launch fica em ~/.n8n e é ela que protege as credenciais

No servidor, ela é definida no deploy pela variável de ambiente N8N_ENCRYPTION_KEY e não muda: é a master key da instância (o que se rotaciona são as data encryption keys, que ficam cifradas no banco)

O erro comum deste passo: subir a VPS primeiro, deixar o n8n gerar uma chave nova e só depois lembrar das credenciais

3. Suba o n8n na VPS com Docker

A imagem oficial fica no registro do próprio projeto:

docker pull docker.n8n.io/n8nio/n8n
docker volume create n8n_data
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

O volume montado em /home/node/.n8n é o que preserva os dados entre reinícios do container

E se liga nisso: mesmo usando PostgreSQL, essa pasta continua guardando a chave de criptografia, os logs da instância e os assets do source control

O erro comum deste passo: rodar sem volume e perder tudo na primeira recriação do container

4. Garanta que ele volte sozinho depois de um reboot

De nada adianta o servidor ser 24 horas se o container não sobe de novo quando a máquina reinicia

Os exemplos de Docker Compose da documentação do n8n usam política de reinício automático:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always

O erro comum deste passo: ficar no docker run com --rm de teste e achar que aquilo é produção

5. Importe os workflows e as credenciais

n8n import:workflow --separate --input=backup/workflows

O --separate lê os arquivos *.json do diretório indicado no --input

O erro comum deste passo: esquecer que o n8n exporta os IDs junto

Se existirem os mesmos IDs no banco de destino, eles são sobrescritos (apagar ou trocar os IDs antes de importar evita isso)

6. Defina o WEBHOOK_URL se estiver atrás de proxy reverso

Sem isso, o n8n mostra e registra endereços que não batem com o seu domínio, e o serviço externo continua chamando o lugar errado

A variável de ambiente WEBHOOK_URL é o que faz as URLs saírem certas nos serviços externos

O erro comum deste passo: copiar tutorial antigo com WEBHOOK_TUNNEL_URL, que foi renomeada pra WEBHOOK_URL na versão 0.227.0 e removida no n8n 1.0

7. Reative os fluxos

Um workflow com trigger automático só executa em produção se estiver salvo, publicado e com o toggle Active ligado

O trigger também não pode ser o Manual Trigger: anexe um trigger de verdade, salve, publique e ligue o toggle

O erro comum deste passo: dar a migração por concluída sem olhar o toggle, e o servidor ficar ligado 24 horas fazendo nada 😛

Migrou e nada dispara: os erros mais comuns e como prevenir

O workflow importado aparece na lista mas não roda:

Sintoma: tá tudo lá, bonitinho, e nenhuma execução aparece

Causa: por padrão o import:workflow desativa cada workflow importado

Correção: reative um por um pelo toggle Active, ou use --activeState=fromJson pra preservar o campo active do JSON (essa flag é suportada apenas em multi-main e queue mode)

Como prevenir: já entre na conta de que a importação chega desligada e trate a reativação como um passo do checklist, não como surpresa

A credencial existe mas falha na execução:

Sintoma: a credencial aparece salva e o nó quebra na hora de autenticar

Causa: a chave de criptografia do destino não é a mesma que cifrou aquela credencial na origem

Correção: definir o N8N_ENCRYPTION_KEY do servidor com a chave da instância original antes de importar

Como prevenir: guardar a chave que está em ~/.n8n no mesmo lugar onde você guarda o backup dos workflows

O webhook continua chamando o endereço local:

Sintoma: o serviço externo dispara e o n8n nunca recebe

Causa: rodando atrás de proxy reverso sem WEBHOOK_URL definida, o n8n mostra e registra a URL errada

Correção: definir a variável e recadastrar a URL no serviço externo

Como prevenir: não usar o tunnel como solução permanente, ele é ferramenta de desenvolvimento e testes locais

Um workflow que já existia no servidor sumiu depois do import:

Sintoma: você importou 12 fluxos e um antigo virou outra coisa

Causa: ID igual no destino, e o n8n sobrescreve

Correção: restaurar do backup do destino (se você tiver feito… e é por isso que se faz)

Como prevenir: apagar ou trocar os IDs antes de importar quando o destino já tem conteúdo

Os dados somem sempre que o container é recriado:

Sintoma: subiu de novo e o n8n pede cadastro inicial como se fosse a primeira vez

Causa: volume não montado em /home/node/.n8n

Correção: criar o volume n8n_data e montar nesse caminho

Como prevenir: tratar esse caminho como o coração da instância, porque ele guarda chave de criptografia, logs e assets do source control

O fluxo em produção está preso no Manual Trigger:

Sintoma: só roda quando você aperta o botão

Causa: o Manual Trigger não gera execução de produção

Correção: anexar um trigger que dispare sozinho, salvar, publicar e ativar

Como prevenir: testar a condição real do trigger antes de considerar o fluxo entregue

Conclusão

O critério de decisão aqui é bem honesto e não tem fórmula mágica nenhuma

Se você quer controle, quer mexer no ambiente e prefere custo previsível, self-hosted na VPS resolve: a Community Edition é gratuita por tempo indeterminado e você paga só a hospedagem

Se você não quer administrar servidor, update, chave e proxy, o Cloud existe pra isso, com 2.500 execuções por mês no Starter

E o próximo passo concreto não é escolher entre os dois, é fazer o backup hoje, antes de qualquer migração

Rode o export, guarde os JSONs, guarde a chave que está em ~/.n8n

Depois teste um trigger de verdade com o seu PC desligado: é esse teste que diz se você tem automação ou se você tem um fluxo bonito que só funciona quando você está olhando 😀

Ah, e se você for experimentar o Cloud pra comparar: o teste gratuito dura 14 dias, expira sozinho sem cobrança e ainda te dá 90 dias pra baixar os workflows depois que ele termina

Então dá pra testar sem medo de ficar com fluxo preso lá dentro

até o próximo post!

Perguntas frequentes

Por que meu workflow agendado não dispara mesmo com o n8n instalado?

Porque um trigger automático só roda em produção se o workflow estiver salvo, publicado e com o toggle Active ligado, e a instância do n8n precisa estar rodando no momento em que a condição do trigger acontece. Se o processo está parado (PC desligado, por exemplo), a execução simplesmente não ocorre, mesmo com tudo configurado certo.

Rodar o n8n numa VPS o tempo todo tem algum custo escondido do próprio n8n?

Não. A Community Edition self-hosted é gratuita por tempo indeterminado, rodando na sua própria infraestrutura. O que você paga é a hospedagem da VPS, não uma licença do n8n.

Como configurar o n8n para reiniciar sozinho se o servidor cair?

Os exemplos de Docker Compose da documentação do n8n usam a política restart: always no serviço do n8n. Assim, se o container cair ou o servidor reiniciar, ele volta a subir sozinho, sem depender de alguém logar e rodar o comando de novo.

O que é a N8N_ENCRYPTION_KEY e o que acontece se eu perder ela?

É a chave gerada automaticamente no primeiro start do n8n e salva na pasta ~/.n8n, usada para criptografar as credenciais antes de gravá-las no banco. Ela também pode ser definida pela variável de ambiente N8N_ENCRYPTION_KEY, funciona como a master key do deploy e não muda depois; se o destino usar uma chave diferente da origem, as credenciais migradas aparecem na lista mas não abrem na hora da execução.

Dá pra usar o modo tunnel do n8n para deixar ele rodando 24 horas em produção?

Não. O modo tunnel é uma ferramenta de desenvolvimento e testes locais, usa cloudflared, exige Docker instalado e a implementação pode mudar entre versões. Para produção o caminho é a Production webhook URL, e rodando atrás de proxy reverso é preciso definir a variável WEBHOOK_URL para o n8n exibir e registrar os endereços corretos.

Como fazer backup completo dos workflows e credenciais pela linha de comando?

A CLI do n8n tem a flag –backup, que é um atalho para –all –pretty –separate, e –output define onde os arquivos são salvos. Vale lembrar que essa exportação leva junto os IDs de workflows e credenciais, então IDs iguais no destino são sobrescritos na importação.