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)

Formação Recomendada

Formação Agentes de IA

Domine a criação de Agentes de IA e Venda para Empresas

• 402 aulas
• 32 projetos
• 38h 19min

Conhecer formação

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)

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!