n8n self-hosted: vale a pena em 2026? Guia real
n8n self-hosted começa com um docker run que leva menos de dois minutos. E é justamente por isso que tanta gente entra nessa por reflexo. O contêiner sobe, o editor abre na 5678, o primeiro webhook responde, e a sensação é de que você acabou de economizar uma assinatura mensal.
Só que “rodar” e “operar” são verbos diferentes. A primeira madrugada em que um webhook crítico para de responder e não tem ninguém de plantão é quando fica claro qual cargo ficou vago nessa história: o de SRE. E o currículo é o seu. O que segue não é comparativo de preço de plano. É uma tentativa de responder à pergunta que importa: em que cenário concreto vale a pena virar o seu próprio time de infraestrutura?
Quem reinicia o container quando o webhook para de responder às 3h da manhã?
Vamos separar dois tipos de queda, porque só um deles o restart: always resolve.
O primeiro é o processo morrer. O processo principal do n8n mantém execuções em memória, e um workflow de agente de IA que segura uma conexão com LLM por um bom tempo vai acumulando consumo. Se o host entrar em pressão, o OOM killer do kernel derruba o contêiner. O Docker sobe de novo em segundos, e as execuções que estavam no meio do caminho simplesmente não existem mais. Sem queue mode, não há persistência de execução: o que estava rodando evapora. É por isso que a documentação de queue mode do n8n existe, e é por isso que ela cobra pedágio em forma de Redis.
O segundo tipo é mais traiçoeiro porque o n8n está de pé o tempo todo. Um padrão comum: o workflow roda liso em desenvolvimento, com poucas execuções por minuto, e engasga em produção sem que o log do n8n mostre erro. O gargalo estava fora dele o tempo todo. Proxy reverso com timeout mal ajustado e sem retry. O nginx, na configuração padrão, corta a leitura em 60 segundos (proxy_read_timeout); o Cloudflare tem limite de 100 segundos para requisições HTTP nos planos que não são Enterprise. Coloque um nó de agente que demora mais que isso atrás dessa pilha e o chamador recebe um timeout enquanto o n8n continua processando, feliz, uma resposta que ninguém vai ler. Isso não é bug do n8n. É configuração de quem colocou a ferramenta na frente da internet sem desenhar o caminho inteiro.
Tem ainda o terceiro tipo, que não é técnico: a pessoa que instalou saiu da empresa, e o conhecimento sobre onde está o .env, qual volume guarda o Postgres e como restaurar o backup saiu junto.
O que o modo community do n8n self-hosted realmente entrega (e a linha exata onde ele para)
Entrega bastante, e é justo reconhecer: editor completo, webhooks, Schedule Trigger, sub-workflows, nós de código, biblioteca de credenciais cifradas, e queue mode com main + workers, sem cobrança por execução, porque a licença não limita volume. Para muita gente, isso resolve.
Mas convém corrigir um reflexo: o n8n não é software open source no sentido OSI do termo. Ele é distribuído sob a Sustainable Use License, um modelo “fair-code” que libera uso interno e modificação, mas restringe oferecer o n8n como serviço para terceiros. Isso importa se você trabalha em consultoria ou pretende empacotar automação para clientes: leia a licença antes de desenhar o produto, não depois.
A linha onde o community para não é em recurso de automação. É em recurso de operação corporativa. A documentação de licenciamento do n8n lista como Enterprise coisas como SSO/SAML e LDAP, RBAC com papéis customizados, External Secrets (Vault, AWS Secrets Manager), log streaming para Datadog/Elastic e o recurso de Environments com Git. Traduzindo: se a sua exigência é “credencial no Vault” e “log no SIEM”, o self-hosted community não te dá isso pronto. Você paga Enterprise ou cola com fita crepe e script próprio.
E tem a parte de IA, que é onde esse debate esquenta. A documentação de agentes de IA do n8n descreve nós de agente, memória, ferramentas e vector stores, cargas que fazem chamadas longas e que, na prática, pedem workers dedicados e controle de concorrência. Isso empurra você direto para queue mode. E queue mode é Redis, Postgres e mais superfície para operar.
n8n self-hosted não é grátis: os custos que não aparecem em nenhuma fatura
Não vou cravar um número de horas por mês porque isso varia demais com volume, criticidade e tolerância a dor. Número inventado não ajuda ninguém. Mas a lista de itens que passam a ser seus é finita e concreta:
- VPS ou servidor próprio, com sistema atualizado e imagem base corrigida.
- Postgres, gerenciado ou não, com backup de verdade:
pg_dumpagendado mais envio para fora do provedor, ou WAL-G/pgBackRest se você quer point-in-time recovery. Backup que nunca foi restaurado é decoração. - Redis, se você for de queue mode.
- TLS com renovação automática (ACME, certbot, Caddy) e alerta quando a renovação falhar.
- Monitoramento e alerta: Uptime Kuma ou Healthchecks.io para o endpoint, Prometheus/Grafana se você quiser métrica de fila, ou um SaaS de observabilidade pago, porque ninguém descobre indisponibilidade por acaso. Descobre pelo cliente reclamando.
- Cadência de upgrade, que é onde mora a maior parte da dor real.
Sobre o upgrade, um padrão que se repete: subir a imagem para uma versão major nova e descobrir que um nó customizado ou uma integração comunitária quebrou. Sem teste antes, a descoberta chega pelo cliente avisando que a automação parou, não pelo monitoramento, porque o monitoramento checava se o contêiner estava vivo, e ele estava.
E o item mais subestimado de todos: a N8N_ENCRYPTION_KEY. Se você não define a variável, o n8n gera uma chave e a guarda no arquivo de configuração da instância. Todas as credenciais salvas são cifradas com ela. Perder essa chave significa perder todas as conexões de uma vez. O backup do banco não te salva, porque o banco tem ciphertext. Trocar a chave também não é “editar variável e reiniciar”: as credenciais antigas param de ser decifráveis até serem salvas novamente, uma a uma. Na prática, a chave precisa viver separada do dump do banco, num cofre de segredo. E cofre nativo é Enterprise, o que te devolve ao parágrafo anterior.
Cloud do n8n: o que você terceiriza e o que continua sendo seu
O que você compra no cloud é exatamente a lista acima, terceirizada: upgrade, backup, disponibilidade, TLS, fila, suporte. Para um time pequeno, isso vale mais do que parece. Vale mais do que a diferença de preço sugere, porque você está comprando noites de sono, não CPU.
O eixo dessa decisão não é preço, é fronteira de responsabilidade. No cloud, outra pessoa é acordada às 3h no seu lugar e o upgrade deixa de ser problema seu. O que não sai da sua mesa: decidir o que pode trafegar para fora da sua rede, quais workflows fazem sentido existir e o que a política da empresa aceita. Nenhum plano gerenciado resolve essas três.
A cobrança por execução entra aqui só como aritmética, não como argumento central. O cloud do n8n cobra por volume de execuções, e execução é uma unidade contraintuitiva: um Schedule Trigger rodando a cada minuto multiplica essa conta pelos minutos do mês inteiro, mesmo que o workflow seja um IF que quase sempre encerra sem fazer nada. Antes de projetar custo, olhe os workflows que fazem polling e pergunte se eles precisam existir nesse intervalo.
Dois detalhes que eu confiro na página de preços em vez de assumir: como retries e execuções de sub-workflow são contabilizados, e quais regiões estão disponíveis na contratação. As regiões públicas do cloud ficam na Europa e nos Estados Unidos, e isso vira decisão de conformidade se o seu contrato ou a LGPD exigir processamento em território brasileiro. Nesse caso não é questão de preço, é de requisito, e requisito não se negocia com desconto.
O ponto de virada: em que cenário o n8n self-hosted passa a fazer sentido de verdade
O self-hosted passa a fazer sentido quando pelo menos um destes for verdade:
- Volume alto e estável. Quando o custo por execução do cloud ultrapassa, com folga, a soma de infra mais horas de engenharia.
- Residência de dado. Exigência contratual, regulatória ou de cliente de manter processamento no Brasil ou on-premise.
- Rede privada. Automação que precisa falar com banco, ERP ou sistema interno que você não quer expor à internet.
- Customização de verdade. Nó customizado, código CJS com dependência exótica, lógica que a versão gerenciada não permite.
- Você já tem plantão. Se existe um time de plataforma rodando de verdade, com alguém que assume a fila quando você tira férias, o self-hosted deixa de ser um segundo emprego e volta a ser só infraestrutura. Esse é o cenário mais subestimado da lista, porque não tem a ver com volume nem com preço: tem a ver com quem atende o telefone.
Quando o n8n self-hosted não vale a pena
O contraponto importa tanto quanto a lista acima, e é onde a maioria dos posts sobre o tema fica devendo.
Time de uma pessoa só, sem plantão e sem ninguém para herdar a operação, é o pior cenário possível. Não porque a pessoa não dê conta no dia a dia, mas porque férias, doença e saída da empresa são eventos e não hipóteses. Se ninguém mais sabe onde mora a chave de criptografia, você não tem uma automação, tem um ponto único de falha com interface bonita.
Volume baixo também derruba a conta. Se os seus workflows rodam algumas centenas de vezes por mês, o custo de execução do cloud é troco, e você estaria pagando em horas de engenharia algo que caberia no cartão sem susto. Fazer self-hosted nesse cenário é escolher o caminho mais caro por motivo ideológico.
E tem a exigência corporativa que já nasce Enterprise: SSO, RBAC customizado, segredo no Vault, log no SIEM. Se isso está no seu requisito desde o primeiro dia, o community não te atende, e montar a versão “com fita crepe” costuma custar mais do que a licença que você estava tentando evitar.
Checklist mínimo antes de migrar
Se depois de tudo isso você ainda quer ir, não vá no reflexo do docker run. Antes de colocar qualquer coisa crítica em produção, eu checaria:
N8N_ENCRYPTION_KEYdefinida, guardada em cofre e fora do dump do banco. Teste a restauração das credenciais com a chave antes de precisar dela de verdade.- Queue mode com Redis com persistência ligada (AOF no mínimo). Redis só em memória derruba a fila junto com o contêiner.
- Backup restaurado pelo menos uma vez, em ambiente separado. Restaurar é o único teste que prova que o backup existe.
- Canary de upgrade em ambiente espelho, com os nós customizados e as integrações comunitárias que você usa. O que quebra em upgrade quase nunca é o core.
- Monitoramento no endpoint do webhook, não só no contêiner, e alerta de expiração de TLS.
- Alguém além de você que saiba onde estão o
.env, o volume do Postgres e a chave. Documentado, não na sua cabeça.
Veredito
Respondendo à pergunta do começo: o n8n self-hosted vale a pena quando você tem volume que justifique, exigência de residência de dado ou rede privada, ou quando já existe um time de plataforma que assume o plantão. Fora disso, você não está economizando dinheiro, está trocando uma assinatura por um cargo. E o cargo é o de SRE, com todas as madrugadas que ele traz junto.
Eu gosto do n8n self-hosted. Rodo, acompanho as releases, acho o editor dele melhor do que a média do mercado. Só não confundo gostar da ferramenta com fingir que operar ela é de graça. O custo real não aparece em nenhuma fatura porque ele é pago em tempo, em plantão e em conhecimento que precisa estar em mais de uma cabeça. Se isso está ok para o seu contexto, vai fundo. Se não está, o cloud cobra por algo que você não tem como comprar em outro lugar: alguém acordando no seu lugar.