O n8n self-hosted é uma das melhores formas de automatizar fluxos de trabalho sem depender de quanto você vai pagar no final do mês. Se você já usou o n8n Cloud e ficou olhando para a fatura quando as execuções começaram a crescer, sabe exatamente do que estou falando.
Tenho workflows rodando em n8n self-hosted há mais de um ano. Não é perfeito, mas para o que uso, funciona muito bem: automações com APIs, notificações, integrações com LLMs e alguns fluxos internos que ninguém pediu para automatizar mas que economizam tempo todo dia. A experiência de operar o próprio ambiente me deu uma visão clara do que vale a pena e onde você vai travar se não se preparar.
Por que rodar n8n self-hosted faz sentido
A premissa é direta: o n8n é open source, você hospeda onde quiser, e não paga por execução. O custo vira só o do servidor, que para a maioria dos casos é bem menor do que o plano Cloud quando você chega em volume.
Mas tem um lado que a galera costuma ignorar: você vira responsável pela operação. Atualização, backup, segurança, disponibilidade. Se o container cai num sábado e você tem um fluxo crítico, é você que vai resolver. Isso não é argumento contra o n8n self-hosted, é só o contrato que você assina ao escolher esse caminho.
Para automações internas, integrações com IA, experimentos e fluxos não críticos, o self-hosted entrega muito mais do que o Cloud pelo mesmo custo. Para um produto SaaS que depende do n8n como infraestrutura central e não tem ninguém para operar, aí pensa melhor antes de escolher.
n8n Cloud vs self-hosted: onde a diferença aparece de verdade
O Cloud cuida de tudo: atualização automática, backup, suporte, SSL. Você paga por isso, e faz sentido quando o seu tempo de operação é mais caro do que a mensalidade.
O n8n self-hosted te dá controle total. Sem limite de workflows, sem limite de execuções dentro da capacidade do seu servidor, sem restrição de nodes. Você pode instalar nodes da comunidade que o Cloud não permite, conectar com recursos internos da rede local e integrar com ferramentas que não têm endpoint público.
A decisão é mais sobre onde você quer colocar esforço do que sobre custo puro.
O que você precisa ter antes de subir
Antes de rodar qualquer coisa, confirma que tem em mãos:
- Um servidor com Docker instalado (VPS, homelab, qualquer máquina com acesso SSH)
- Um domínio ou subdomínio apontando para esse servidor, ou acesso via IP interno
- Pelo menos 1GB de RAM disponível (2GB é mais confortável na prática)
- Uma estratégia de backup para os dados do n8n (workflows, credenciais, execuções)
Se você ainda está começando com Docker Compose e não se sente confortável com o ambiente, o artigo Docker Compose do zero: sobe seu primeiro ambiente em menos de 30 minutos é o lugar certo para começar antes de chegar aqui.
Como subir o n8n self-hosted com Docker
O jeito mais direto é usar o repositório de hosting oficial do n8n com Docker Compose. A documentação de self-hosting do n8n tem os arquivos de referência e é bem clara sobre as variáveis de ambiente que você precisa configurar.
O fluxo de instalação básica:
- git clone https://github.com/n8n-io/n8n-hosting.git && cd n8n-hosting/docker-compose/withPostgres
- cp .env.example .env (edite as variáveis antes de subir)
- docker compose up -d
- docker compose logs -f n8n (confirme que subiu sem erro)
Isso sobe o n8n com PostgreSQL como banco de dados. Use PostgreSQL desde o início. O SQLite padrão não escala bem e não é recomendado para nada além de testes rápidos.
Configuração mínima que você não pode pular
Tem algumas variáveis de ambiente que, se você ignorar, vai sentir depois.
N8N_ENCRYPTION_KEY: gerada uma vez, protege todas as credenciais salvas. Se você perder essa chave e restaurar de um backup, as credenciais ficam inacessíveis. Guarda em lugar seguro, fora do próprio servidor.
N8N_HOST e N8N_PROTOCOL: define a URL base do seu n8n. Se não configurar direito, os webhooks não funcionam, porque o n8n vai gerar URLs internas que nenhum serviço externo consegue alcançar.
N8N_WEBHOOK_URL: essa é a fonte de dor número um de quem sobe o n8n self-hosted atrás de reverse proxy. Defina explicitamente com a URL pública que você vai usar. Sem isso, as URLs de webhook vão apontar para o endereço interno do container e nenhuma integração externa vai funcionar.
Para colocar o n8n atrás de HTTPS com Traefik, o artigo Traefik com Docker Compose: reverse proxy sem dor de cabeça cobre exatamente esse cenário e já inclui o exemplo de configuração que funciona.
Conectando o n8n com modelos de linguagem
Aqui está um dos motivos principais pelo qual uso o n8n self-hosted no lugar do Cloud: liberdade para chamar qualquer endpoint sem restrição de plano.
Se você tem um Ollama rodando localmente, o n8n consegue chamar a API dele direto na rede interna, sem exposição externa. Funciona bem para automações que precisam de processamento de texto simples sem depender de API paga.
Para fluxos que usam LLMs de provedores como Anthropic ou OpenAI, o n8n tem nodes nativos. Mas a vantagem do self-hosted é poder colocar um gateway unificado como o LiteLLM na frente desses modelos. Assim você troca de provedor ou modelo sem precisar reconfigurar cada workflow individualmente.
O n8n também tem um node de AI Agent nativo que usa LangChain internamente. Para casos simples, funciona. Para fluxos mais complexos com memória de longo prazo ou múltiplos agentes coordenados, o n8n começa a mostrar limitações e você provavelmente vai precisar de uma implementação separada.
O que o n8n self-hosted não resolve por você
Monitoramento não vem incluso. Você não tem painel de saúde, não tem alerta de falha, não tem métrica de execução fora da interface do próprio n8n.
Para isso, ou você integra com Prometheus e Grafana, ou pelo menos configura um healthcheck simples que notifica quando o container cai. O artigo Monitoramento de graça: Prometheus e Grafana com Docker Compose é um bom ponto de partida para adicionar visibilidade sem adicionar complexidade desnecessária.
Atualização também é manual. O n8n lança versões com frequência, e algumas trazem breaking changes em nodes específicos. Minha recomendação: nunca atualiza em sexta, sempre lê o changelog antes e testa em ambiente separado se você tem fluxos críticos rodando.
Perguntas frequentes
Preciso de um VPS dedicado para rodar o n8n self-hosted?
Não. O n8n roda em qualquer máquina com Docker, incluindo homelab local. A diferença está na disponibilidade: um VPS fica no ar 24h sem você precisar fazer nada; um servidor doméstico depende de você não desligar a máquina. Para fluxos críticos, VPS. Para experimentos, homelab resolve bem.
Quanto o n8n self-hosted consome de recurso?
Para uso moderado, até algumas centenas de execuções por dia, 1GB de RAM é suficiente. Se você tem workflows pesados com processamento paralelo ou chamadas encadeadas a LLMs, 2GB é mais seguro. CPU raramente é o gargalo nesses cenários.
Os dados ficam no meu servidor mesmo?
Sim. Workflows, credenciais e histórico de execuções ficam no banco que você configurou. Nenhum dado passa pelo servidor do n8n. Esse é um dos motivos principais pelo qual prefiro self-hosted para fluxos que lidam com dados internos ou credenciais sensíveis.
Posso migrar do n8n Cloud para o self-hosted?
Pode. O n8n exporta workflows em JSON de forma nativa. Credenciais não migram automaticamente por razões de segurança, então você vai precisar reconfigurá-las no ambiente novo. O processo não é difícil, mas reserva tempo para testar cada workflow depois da migração antes de desligar o Cloud.
O n8n self-hosted recebe as mesmas atualizações do Cloud?
Sim, o repositório open source recebe as mesmas features. A diferença é que no Cloud as atualizações são automáticas. No self-hosted, você controla quando atualizar, o que na prática é uma vantagem quando você não quer surpresas em produção sem avisar.
Concluindo
O n8n self-hosted funciona. É uma das ferramentas que mais me deu retorno em automação com custo controlado. Se você já tem infra com Docker e quer parar de pagar por execução, a curva de entrada é pequena e o setup leva menos de uma tarde.
O que mais engana quem está começando é achar que sobe e esquece. Com uma estratégia de backup definida desde o primeiro dia e algum tipo de alerta quando o serviço cair, o n8n self-hosted roda bem por muito tempo sem precisar de atenção constante.
O que fazer agora:
- Sobe um ambiente de teste com o Docker Compose oficial antes de ir para produção
- Configura o webhook URL e testa com um fluxo simples de HTTP trigger antes de migrar qualquer automação existente
- Define uma rotina de backup para o volume do banco de dados desde o início, não depois que você perder algo