Hospede seu próprio n8n em um VPS.
Seu motor de automação, suas credenciais, seu hardware.

O n8n é um motor de automação de fluxos de trabalho: uma tela visual onde você conecta um trigger — um webhook, um agendamento, uma linha nova em um banco de dados, uma mensagem em uma fila — a uma cadeia de nodes que chamam APIs, transformam dados, ramificam por condições, rodam JavaScript ou Python arbitrário, e entregam o resultado para o que vem a seguir. Várias centenas de nodes de integração já vêm de fábrica, além de um node genérico HTTP Request que cobre tudo o mais. Desde a linha 1.x ele também carrega nodes AI Agent e LLM, que é por isso que boa parte das pessoas que o instalam em 2026 está construindo agentes em vez da encanação clássica de ETL.

A parte que importa antes de você digitar um único comando é a licença, porque o n8n não é open source no sentido da OSI e a diferença não é acadêmica. O núcleo é distribuído sob a Sustainable Use License: uma concessão mundial, não exclusiva e livre de royalties para usar, copiar, modificar e distribuir o software para fins comerciais internos e para uso pessoal ou não comercial. O que ela retém é o direito de cobrar de terceiros pelo n8n ou por uma derivação dele — que é a cláusula que descarta construir um produto pago de "n8n gerenciado" em cima dele. Separadamente, qualquer arquivo que carregue .ee. no nome ou .ee no caminho é excluído inteiramente dessa licença e exige uma n8n Enterprise License paga.

Em termos simples: rodar o n8n em um VPS para automatizar a sua própria empresa, o trabalho dos seus próprios clientes entregue como um serviço que você presta, ou a sua própria vida pessoal, está dentro da concessão gratuita e sempre esteve. Vender n8n-como-produto-de-hospedagem não está. Quase toda discussão de "o n8n é realmente gratuito?" na internet é duas pessoas falando sem se entender através dessa linha.

O lado do custo. O n8n Cloud tem preço por execução: o plano Starter é €20 por mês cobrado anualmente para 2,500 execuções, o Pro é €50 por mês para 10,000, o Business é €667 por mês para 40,000. Auto-hospedado, a contagem de execuções não é nem um item de cobrança — ela é limitada por quanta CPU e memória a máquina tem. Um fluxo de trabalho que faz polling em uma API a cada cinco minutos já queima 8,640 execuções por mês sozinho; no Cloud esse único fluxo de trabalho já força o tier Pro, e em um VPS de $3.90 isso é um erro de arredondamento contra a CPU ociosa.

Preços do Cloud conforme publicados no n8n.io em agosto de 2026, cobrados anualmente; a cobrança mensal custa mais. A troca não é só dinheiro — hospedar você mesmo transfere atualizações, backups, renovação de TLS e uptime para o seu lado da linha.

No painel: Order → VPS → Sentinel, imagem Debian 12. Nenhum endereço de e-mail é exigido para abrir a conta, nenhum documento de identidade é solicitado em nenhum momento, e a fatura é quitada em Monero, Bitcoin, Lightning ou qualquer um dos outros ativos suportados. Escolha o bastion pela latência até os serviços que você automatiza, e não até você mesmo — um servidor de automação conversa com APIs muito mais do que conversa com você.

Depois crie o registro DNS antes de tocar no servidor: um registro A para n8n.example.com apontando para o IPv4 do VPS, e um registro AAAA se você usa IPv6. Isso precisa ser feito primeiro, porque o Caddy pede um certificado ao Let's Encrypt no momento em que o stack sobe, e um pedido de certificado para um nome que não resolve falha — depois recua, e você passa vinte minutos se perguntando por que o site está inacessível.

Dê um minuto para o DNS propagar e confirme a partir da sua própria máquina antes de continuar:

dig +short n8n.example.com
# → the IPv4 of your VPS, and nothing else

Antes de qualquer coisa escutar em uma porta pública, siga o checklist de hardenização da primeira hora — SSH somente por chave, um firewall que permite 22, 80 e 443 e mais nada, e atualizações de segurança não supervisionadas. Um servidor de automação é um cofre de credenciais; ele merece a hora inteira.

Crie o diretório e gere os dois segredos primeiro. Gere-os agora, nessa ordem, e cole-os no .env conforme for gerando — a chave de criptografia em particular precisa existir antes do primeiro boot do n8n, não depois.

mkdir -p /opt/n8n && cd /opt/n8n
openssl rand -hex 32   # → N8N_ENCRYPTION_KEY
openssl rand -hex 24   # → POSTGRES_PASSWORD

/opt/n8n/.env

DOMAIN=n8n.example.com
LETSENCRYPT_EMAIL=you@example.com
GENERIC_TIMEZONE=Europe/Stockholm

N8N_ENCRYPTION_KEY=paste_the_32_byte_hex_here
POSTGRES_DB=n8n
POSTGRES_USER=n8n
POSTGRES_PASSWORD=paste_the_24_byte_hex_here

Trave o arquivo imediatamente — ele guarda a chave de toda credencial que a instância algum dia vai armazenar:

chmod 600 /opt/n8n/.env

/opt/n8n/docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 10

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_EDITOR_BASE_URL=https://${DOMAIN}
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - N8N_BLOCK_ENV_ACCESS_IN_NODE=true
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_VERSION_NOTIFICATIONS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  caddy_config:
  pg_data:
  n8n_data:

/opt/n8n/Caddyfile

{$DOMAIN} {
    encode zstd gzip
    tls {$LETSENCRYPT_EMAIL}
    reverse_proxy n8n:5678
}

Duas decisões de design que vale a pena nomear. Primeiro, o n8n não publica uma porta. Só o Caddy vincula as portas 80 e 443; o n8n escuta na 5678 dentro da rede do Compose, onde nada fora do host consegue alcançá-lo. Um número surpreendente de instâncias de n8n auto-hospedadas está na internet pública na porta 5678 sem TLS na frente, e mecanismos de busca para serviços expostos as indexam. Segundo, o volume de dados do n8n continua montado mesmo que o PostgreSQL agora guarde os fluxos de trabalho — esse diretório ainda carrega as configurações da instância, os arquivos de log e os ativos de controle de versão.

Suba o stack:

cd /opt/n8n
docker compose up -d
docker compose logs -f caddy   # watch the certificate being issued

Um n8n que inicializa, mostra o editor e executa um teste manual ainda não é um n8n funcional. A metade que quebra silenciosamente são os webhooks de entrada, e ela quebra de formas que parecem culpa do serviço de terceiros.

WEBHOOK_URL. Sem ela, o n8n constrói as URLs de webhook a partir de N8N_HOST e N8N_PORT e te entrega algo como http://localhost:5678/webhook/abc — que você então cola no Stripe ou no GitHub, onde nunca poderá ser alcançada. O arquivo Compose acima define WEBHOOK_URL para a raiz HTTPS pública, que é o que o editor vai exibir e o que o mundo exterior realmente consegue chamar.

N8N_EDITOR_BASE_URL. A URL pública que o n8n usa para os links nos e-mails que envia — redefinições de senha, convites de usuário. Errado aqui significa um link de convite apontando para localhost, o que vira um chamado de suporte de um colega em vez de uma integração quebrada.

N8N_PROXY_HOPS. O n8n lê o IP do cliente a partir do X-Forwarded-For, e só confia em tantos saltos quanto esse número disser. Com um proxy reverso na frente — o Caddy neste stack — o valor é 1. Coloque o Cloudflare na frente do Caddy e ele vira 2. Deixe no padrão 0 e toda requisição parece vir do próprio proxy, o que quebra silenciosamente os rate limits e qualquer lógica baseada em IP nos seus fluxos de trabalho.

N8N_SECURE_COOKIE. O padrão é true, o que significa que o cookie de sessão só é enviado por HTTPS. Essa é a configuração correta e este stack a satisfaz. Vale a pena saber porque isso explica o sintoma clássico de uma primeira tentativa em http puro: o formulário de login aceita a senha e depois te devolve para o formulário de login, para sempre. A correção é TLS, não desligar a flag.

Teste direito. Crie um fluxo de trabalho com um node Webhook, ative o fluxo de trabalho, copie a Production URL, e então a chame a partir de uma máquina que não seja o servidor:

curl -i https://n8n.example.com/webhook/<path>
# → HTTP/2 200, and a new execution visible in the editor

A distinção que faz todo mundo tropeçar uma vez: a Test URL só escuta enquanto você tem o editor aberto com "Listen for test event" armado. A Production URL só existe quando o fluxo de trabalho está com o botão Active ligado. Um webhook que funciona no editor e dá 404 em produção é quase sempre um fluxo de trabalho inativo.

Por padrão o n8n roda em modo regular: o mesmo processo que serve o editor e recebe webhooks também executa os fluxos de trabalho. É simples e funciona bem até um fluxo de trabalho longo começar a fazer os outros esperarem. O sintoma é inconfundível — execuções ficam em "running" por minutos, o editor fica lento, e um webhook que deveria responder em 200 ms responde em oito segundos.

O modo fila divide o trabalho. A instância principal mantém o editor, os triggers e os endpoints de webhook; ela empurra IDs de execução para o Redis; processos worker separados os puxam, carregam o fluxo de trabalho do PostgreSQL, o executam, e reportam de volta pelo Redis. Três regras decorrem dessa arquitetura e todas as três mordem quem as ignora: toda instância precisa compartilhar o mesmo banco de dados PostgreSQL, toda instância precisa carregar a mesma N8N_ENCRYPTION_KEY, e SQLite não é suportado de jeito nenhum.

As adições ao arquivo Compose são um serviço Redis e um serviço worker, que é a mesma imagem do n8n rodada com o comando worker:

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--save", "60", "1", "--appendonly", "no"]
    volumes:
      - redis_data:/data

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker --concurrency=5
    depends_on:
      - redis
      - postgres
    environment:
      # the SAME encryption key and the SAME database as the main instance
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - TZ=${GENERIC_TIMEZONE}

Adicione EXECUTIONS_MODE=queue e QUEUE_BULL_REDIS_HOST=redis também ao serviço principal do n8n — os dois lados precisam concordar sobre o modo. Duas opções valem a pena configurar desde o primeiro dia: OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS=true, para que clicar em "Test workflow" no editor não trave o processo principal, e N8N_GRACEFUL_SHUTDOWN_TIMEOUT, que por padrão é 30 segundos e decide por quanto tempo um worker pode terminar seu job atual durante um redeploy. Se seus fluxos de trabalho costumam rodar por mais de meio minuto, aumente esse valor — ou todo deploy mata trabalho em andamento.

Não comece por aqui. O modo fila adiciona duas partes móveis e uma classe de falha que o modo regular simplesmente não tem. Fique no modo regular até você ver a fila crescendo ou um fluxo de trabalho bloqueando outro, depois adicione um único worker na mesma máquina antes de adicionar uma segunda máquina. Essa progressão — Sentinel em modo regular, Garrison com um worker, Ravelin com três — cobre tudo, exceto uma implantação genuinamente grande.