N8N: Modos de execução

há 1 mês 21

Saudações.

Vou ensinar como funciona a arquitetura do N8N para execução de programas (workflows).

Pré-requisitos:

Ambiente capaz de rotas N8N (VPS, VM, Linux, …);
Acesso à Internet durante os procedimentos.

1 – Modo simples (SQLITE)

Nesse modo o N8N não requer nenhuma configuração especial, basta rodar o “n8n start” que ele já estará pronto pra uso.

Sua principal característica é rodar tudo em um único processo e salvar tudo em um arquivo SQLITE (banco de dados inteiro em um único arquivo).

Esse modo é muito bom para testar, brincar, aprender, dar aulas, mas é totalmente inadequado a execuções em produção (produto online, SaaS, Agentes de IA, …).

Um workflow que alocar muita memória (listas grandes) ou entrar em loop compromete todo o ambiente, até mesmo o editor:

2 – Modo fila

O objetivo do modo fila é separar as partes para que elas não sejam afetadas por falhas e possam ser reiniciadas ou duplicadas (escala horizontal).

Par que as partes se comuniquem e troquem serviços e mensagens o N8N faz uso de um serviço de mensagens próprio composto pelo Redis (pub/sub de eventos e cache de chaves) e pelo PostgreSQL (SQL com suporte a transações).

No modo fila o N8N roda desacoplado em 3 partes principais:

Editor: responsável pela configuração do ambiente e pela administração, edição e testes dos workflows. Ele preserva todas as capacidades do modo simples, podendo rodar workflows no seu núcleo, embora isso seja desencorajado.
Worker: responsável pela execução do workflow (processa os nodes um a um em um ambiente sandblox);
Webhook: responsável pela terceirização do servidor HTTP e dos gatilhos de execuções baseados no protocolo HTTP (Webhook, SSE, MCP Server);

Diagrama do modo fila:

As partes podem rodar em qualquer processador ou servidor, sendo apenas necessário que elas se comuniquem via IP com os servidores Redis e PG.

Escalando:

3 – Modo fila com task-runner

O modo fila ainda possui uma pequena fragilidade: tarefas grandes e bugs ainda podem travar o worker, que mesmo rodando separado pode bugar e causar um efeito cascata quando outros workers assumirem o trabalho e também travaram.

Travamentos são mais comuns em códigos do usuário (node Code).

A arquitetura mais segura é separar a execução de código Javascript e Python do usuário para outro serviço segregado: o task-runner.

Ele é um processo que se conecta ao worker: sempre que códigos forem solicitados no workflow o task-runner fica responsável por receber o ambiente (variáveis de ambiente, variáveis do workflow, INPUT do node) e executar o código JS/PY.

Se o task-runner travar, travou! Falha no node Code e o ambiente é preservado.

Diagrama do N8N com TR:

Com essas informações você conseguirá entender melhor qual modo escolher e como configurar seu ambiente!

4 – Modo simples (SQLITE) com task-runner

Rodar o N8N com banco SQLITE, embora simples, irá requerer a implementação do task-runner nas futuras versões (v2). Não será mais viável nem possível executar código Javascript ou Python em “Node Code” sem ele.