O n8n tem uma característica que o distingue da maioria das ferramentas de automação: você pode rodá-lo na sua própria infraestrutura. Para muita equipe, é justamente por isso que ele entra na avaliação — dados sensíveis que não podem transitar por um serviço de terceiros, integrações com sistemas internos que não estão expostos à internet, ou simplesmente volume de execuções que torna o modelo de assinatura caro.

A decisão de hospedar por conta própria costuma ser fácil. O que vem depois nem tanto. Automação tem uma particularidade cruel: quando ela para, ninguém percebe imediatamente. Um site fora do ar gera reclamação em minutos; um fluxo que deixou de rodar às três da manhã pode passar dias despercebido.

Este guia cobre o que realmente importa antes de colocar o n8n em produção: requisitos, decisões de arquitetura, o que a licença permite e os erros que mais derrubam instâncias — inclusive um que a documentação avisa e quase todo mundo ignora.

O que é o n8n, em uma frase técnica

O n8n é uma plataforma de automação de fluxos de trabalho que conecta APIs, serviços e bancos de dados por meio de um editor visual, com a possibilidade de inserir código quando o nó pronto não resolve.

Do ponto de vista de infraestrutura, ele é uma aplicação Node.js que expõe uma interface web, mantém estado em um banco de dados e executa processos disparados por agendamento, por webhook ou manualmente. Essa última parte é a que define os requisitos: é uma aplicação que precisa estar sempre ativa e que recebe chamadas externas.

Antes de tudo: o que a licença permite

Esta seção vem primeiro de propósito, porque é o ponto que gera mais retrabalho — sobretudo em agências.

O n8n não é distribuído sob uma licença de código aberto aprovada pela OSI. Ele usa a Sustainable Use License, que a própria empresa classifica como *fair-code*. O código é público e a edição Community é gratuita, mas o uso tem limites definidos.

Em termos práticos, conforme a documentação oficial:

• Permitido: usar, modificar e operar o n8n para fins internos do seu negócio, incluindo automações que geram receita para a sua empresa.
• Permitido: prestar serviços de consultoria e suporte, como construir fluxos para clientes. Essa restrição existia na licença anterior e foi removida.
• Não permitido sem licença comercial: oferecer o n8n como serviço hospedado a terceiros, revendê-lo, embuti-lo em um produto ou disponibilizá-lo com outra marca.

A fronteira que costuma confundir agências é esta: construir automações para um cliente é consultoria e está coberto. Hospedar uma instância e cobrar do cliente pelo acesso a ela se aproxima de “n8n como serviço”, que não está. Arquiteturas em que o cliente recebe acesso à interface do n8n em uma instância que você opera comercialmente merecem leitura atenta da licença — e, se o modelo de negócio depender disso, consulta jurídica.

Vale registrar também que arquivos marcados com .ee. no repositório não estão sob a Sustainable Use License e exigem licença Enterprise. Recursos como SSO e versionamento por Git pertencem a esse conjunto.

Hospedagem própria ou n8n Cloud: quando cada uma faz sentido

A escolha raramente é sobre preço de software — a edição Community não cobra licença. É sobre onde o custo aparece.

Hospedagem própria faz sentido quando: os dados processados não podem sair da sua infraestrutura; existem integrações com sistemas internos não expostos à internet; o volume de execuções é alto o bastante para que o modelo por execução fique caro; ou você precisa de controle sobre versões, nós customizados e ambiente de execução.

O serviço gerenciado faz sentido quando: não há ninguém para administrar servidor; o volume é baixo; e a prioridade é começar rápido.

A conta honesta: o software é gratuito, a infraestrutura não. Some servidor, banco de dados, domínio, certificado, e principalmente o tempo de configurar e manter. Para um volume pequeno, hospedar por conta própria costuma custar mais em horas do que economiza em assinatura.

Requisitos de infraestrutura

O n8n é modesto em recursos quando ocioso e bastante variável quando executa. O consumo depende menos do número de fluxos e mais do que eles fazem: um fluxo que move poucos registros por hora é irrelevante; um que processa arquivos, imagens ou grandes volumes de JSON consome memória de forma significativa.

Os elementos que definem a necessidade:

Elemento	O que considerar
Sistema operacional	Distribuição Linux estável com suporte de longo prazo é o padrão
Node.js	Necessário apenas na instalação direta; com Docker, vem na imagem
Banco de dados	SQLite por padrão; PostgreSQL para produção
Memória	Definida pelo tipo de dado que os fluxos processam, não pela quantidade de fluxos
CPU	Importa em execuções paralelas e em transformações pesadas
Disco	Cresce com o histórico de execuções — item frequentemente esquecido
Rede	IP e domínio próprios para receber webhooks

Este artigo não sugere números de RAM e CPU de propósito: dimensionar sem conhecer o perfil dos fluxos produz recomendação inútil. O dimensionamento tem tratamento dedicado em conteúdo próprio deste blog.

O que vale registrar aqui é o requisito não negociável: hospedagem compartilhada não serve. O n8n precisa de um processo permanentemente ativo, porta própria e acesso ao sistema — características de um servidor com acesso root.

As quatro decisões de arquitetura que importam

1. Docker ou instalação direta

A instalação via Docker é a forma recomendada pela documentação oficial e a que menos gera problema. Ela isola dependências, torna a atualização previsível — troca-se a tag da imagem — e evita conflitos com a versão de Node.js do sistema.

A instalação direta via npm é viável e faz sentido em cenários específicos, mas amarra a aplicação à versão de Node.js do servidor e transforma cada atualização em um evento de risco.

2. SQLite ou PostgreSQL

Esta é a decisão que mais causa arrependimento tardio.

O n8n usa SQLite por padrão. Funciona bem para testes e para uso pessoal leve. Em produção, o SQLite passa a ser um gargalo: ele não lida bem com escritas concorrentes, e o histórico de execuções cresce rápido, degradando a interface e as consultas.

Use PostgreSQL desde o início. Migrar depois é possível, mas envolve exportar e reimportar dados em uma instância que já está em operação — trabalho que se evita com uma variável de ambiente definida no primeiro dia.

3. Proxy reverso e HTTPS

O n8n escuta em uma porta própria e não deve ser exposto diretamente à internet. O padrão é colocar um servidor web à frente atuando como proxy reverso, responsável por terminar o TLS e encaminhar o tráfego.

HTTPS não é opcional aqui, por dois motivos: a interface recebe credenciais de todos os serviços integrados, e muitos provedores só entregam webhooks em endpoints com certificado válido.

Um detalhe que gera confusão: o n8n precisa saber qual é a sua URL pública para gerar os endereços de webhook corretamente. Se essa configuração não for informada, os fluxos exibem endereços internos que não funcionam de fora.

4. Fuso horário

Parece detalhe e não é. O n8n usa fuso padrão próprio se nada for configurado, e todo agendamento passa a disparar em horário diferente do esperado. Definir o fuso na configuração inicial evita uma investigação improdutiva semanas depois.

O erro que mais derruba instâncias

Vale isolar este ponto, porque ele é a causa mais comum de servidores de n8n que “pararam do nada”.

Cada execução de fluxo é registrada no banco de dados, com os dados que passaram por ela. Sem uma política de retenção, esse histórico cresce indefinidamente. Uma instância com fluxos frequentes acumula centenas de milhares de registros em poucos meses.

O resultado é previsível: interface lenta, consultas demoradas e, no limite, disco cheio — o que derruba a aplicação e o banco juntos.

A documentação do n8n oferece variáveis de ambiente para limitar a retenção de execuções por idade e por quantidade. Configurar isso faz parte da instalação, não da manutenção futura. Vale combinar a retenção com monitoramento de espaço em disco, porque a falha por disco cheio costuma acontecer sem aviso prévio.

Segurança mínima antes de colocar em produção

Uma instância de n8n concentra as credenciais de todos os sistemas que ela integra. Comprometê-la é comprometer o conjunto.

1. Autenticação ativa e usuários nomeados. Nunca deixar a instância acessível sem autenticação, nem que seja “só por enquanto”.
2. Chave de criptografia preservada. O n8n criptografa as credenciais armazenadas com uma chave gerada na primeira execução. Perdê-la significa perder o acesso a todas as credenciais salvas — e ela precisa estar no backup.
3. HTTPS obrigatório, com renovação automática do certificado.
4. Superfície de rede reduzida. Apenas as portas necessárias abertas; a porta da aplicação acessível somente pelo proxy reverso.
5. Atualizações acompanhadas. O n8n evolui rápido; versões desatualizadas acumulam correções não aplicadas.
6. Cuidado com o nó de código. Ele executa código arbitrário. Em instâncias com vários usuários, isso é uma decisão de segurança, não de conveniência.

Backup: o que precisa ser salvo

Backup de n8n não é backup de arquivos. Três elementos precisam estar cobertos:

• O banco de dados, que contém fluxos, credenciais criptografadas, histórico e configurações.
• A chave de criptografia, sem a qual as credenciais do backup são inúteis.
• Os arquivos de configuração e as variáveis de ambiente, que reproduzem o comportamento da instância.

E a regra que vale para qualquer backup: ele só existe depois de uma restauração testada. Restaurar em um ambiente separado uma vez, antes de precisar, é o que separa um backup real de uma pasta com arquivos.

Quando uma instância única deixa de bastar

A arquitetura descrita até aqui — uma instância, um banco, um proxy — atende à maior parte dos casos. Ela encontra limite em três situações: volume alto de execuções simultâneas, fluxos longos que ocupam a instância por muito tempo e cenários em que a indisponibilidade da automação tem custo direto.

A resposta do n8n para isso é o modo de fila, com uma instância principal recebendo os disparos e processos separados executando os fluxos. É uma mudança relevante de arquitetura, que envolve componente adicional e mais pontos de operação — assunto para conteúdo próprio, e não algo a improvisar quando o problema já apareceu.

Conclusão

Hospedar o n8n por conta própria é uma decisão sensata quando existe motivo real — dados que não podem sair, integrações internas, volume alto ou necessidade de controle. Não é uma decisão apenas de economia, porque o software gratuito vem acompanhado de infraestrutura e manutenção que têm custo.

Se for para fazer, três escolhas concentram quase todo o risco e são baratas no primeiro dia: PostgreSQL em vez de SQLite, política de retenção de execuções configurada desde o início e backup que inclua a chave de criptografia. Instâncias que falham quase sempre falharam em uma dessas três.

Se você está avaliando onde colocar a sua instância, o ponto de partida é um servidor com recursos reservados e acesso root — hospedagem compartilhada não executa esse tipo de aplicação. Conheça o Cloud Server para n8n da TBF Host e avalie a configuração adequada ao perfil dos seus fluxos.

Perguntas frequentes

O n8n é gratuito para uso comercial?

A edição Community é gratuita e a Sustainable Use License permite usar o n8n para fins internos do seu negócio, incluindo automações que geram receita. O que não é permitido sem licença comercial é oferecer o n8n como serviço hospedado a terceiros, revendê-lo ou embuti-lo em um produto com outra marca.

Posso hospedar o n8n em hospedagem compartilhada?

Não. O n8n é uma aplicação Node.js que precisa de um processo permanentemente ativo, porta própria e acesso ao sistema operacional. Esses requisitos exigem um servidor com acesso root, como um Cloud Server ou VPS.

Preciso usar Docker para instalar o n8n?

Não é obrigatório, mas é a forma recomendada pela documentação oficial e a que gera menos problemas. O Docker isola dependências, torna a atualização previsível e evita conflitos com a versão de Node.js instalada no servidor.

Devo usar SQLite ou PostgreSQL no n8n?

PostgreSQL, desde o primeiro dia, em qualquer instância de produção. O SQLite é o padrão e funciona para testes e uso pessoal leve, mas não lida bem com escritas concorrentes e degrada conforme o histórico de execuções cresce. Migrar depois exige exportar e reimportar dados em uma instância já em operação.

Por que minha instância de n8n ficou lenta com o tempo?

A causa mais comum é o acúmulo do histórico de execuções no banco de dados. Cada execução é registrada com os dados que passaram por ela e, sem política de retenção configurada, esse histórico cresce indefinidamente até degradar a interface e, no limite, encher o disco.

O que preciso incluir no backup do n8n?

O banco de dados, que guarda fluxos, credenciais criptografadas e configurações; a chave de criptografia, sem a qual as credenciais do backup não podem ser lidas; e os arquivos de configuração com as variáveis de ambiente. Um backup só é confiável depois que a restauração foi testada.

Por que os webhooks do meu n8n não funcionam?

O motivo mais frequente é a instância não conhecer a própria URL pública, o que faz o n8n gerar endereços internos inacessíveis de fora. Também é comum o endpoint não estar servido por HTTPS com certificado válido, já que muitos provedores só entregam chamadas a endereços seguros.

Quando preciso de mais de uma instância de n8n?

Quando há volume alto de execuções simultâneas, fluxos longos que ocupam a instância por muito tempo ou cenários em que a parada da automação tem custo direto. A resposta para esses casos é o modo de fila, com processos separados executando os fluxos — uma mudança de arquitetura que exige planejamento próprio.