n8n auto-hospedado: como rodar o n8n no seu próprio servidor

Faz seis meses que você vê sua fatura do Zapier só subir.

Cada novo fluxo de trabalho acrescenta mais um item à conta, e cada etapa de ação bem-sucedida conta como uma tarefa. A fatura mensal já custa mais do que sua ferramenta de gestão de projetos.

Você começa a pesquisar alternativas no Google e chega ao n8n, uma plataforma de automação que você pode auto-hospedar no seu próprio servidor virtual privado (VPS) pelo preço de um servidor pequeno.

Sem cota de execuções. Sem preço por tarefa. Sem contas surpresa quando suas automações decolarem.

E sim, nós mostramos tudo, comando por comando: de um servidor Ubuntu zerado até uma instância funcionando com HTTPS, backups e uma restauração testada.

O que é o n8n e por que as pessoas estão auto-hospedando?

O n8n é uma plataforma de automação de fluxos de trabalho que permite conectar apps, mover dados entre serviços e criar automações complexas em um editor visual. Pense nele como o motor por trás de quando X acontecer, faça Y e Z, só que você arrasta nós e desenha conexões em vez de escrever código.

O projeto já passou de 200.000 estrelas no GitHub, e sua imagem oficial do Docker registra mais de 100 milhões de downloads. Tem muito servidor por aí rodando n8n.

A plataforma é distribuída sob a Sustainable Use License, e vale entender essa licença antes de se comprometer. Ela não é open source tradicional (o próprio n8n diz que não usa o termo, já que licenças aprovadas pela OSI não podem restringir o uso), mas também não é fechada. Você pode usá-la livremente para os fins internos do seu negócio. O que você não pode é vender um produto, serviço ou módulo cujo valor venha inteira ou substancialmente da funcionalidade do n8n.

As pessoas auto-hospedam o n8n porque a conta se inverte quando você vai além do uso básico. O n8n Cloud começa em €20/mês (com cobrança anual) para 2.500 execuções no plano Starter e, se você tem algum volume de verdade, esses limites aparecem rápido.

E na sua própria VPS? Nenhuma cota de execuções, controle sobre os dados que sua instância do n8n armazena e nenhuma conta de licenciamento ou de execuções do n8n. Ainda assim, servidor, domínio, armazenamento de backup e administração continuam tendo custos. As execuções em si não custam nada a mais. Um volume maior consome mais memória e armazenamento, mas isso é uma questão de dimensionamento (que explicamos abaixo), não de cobrança.

O que você pode automatizar com o n8n?

As mais de 400 integrações do n8n cobrem muita coisa, e os nós criados pela comunidade ampliam ainda mais a lista. O n8n também é uma das muitas alternativas auto-hospedadas a ferramentas SaaS, e a mesma lógica vale para tudo, de CRM a gestão de projetos.

Algumas configurações comuns:

• CRM e roteamento de leads. Sincronize contatos entre seu CRM, sua plataforma de e-mail e o Slack quando novos leads chegarem.
• Fluxos acionados por webhook. Responda em tempo real a eventos de processadores de pagamento, envios de formulário ou commits no GitHub.
• Automação de pipelines de dados. Puxe dados de APIs, transforme-os e envie para bancos de dados ou planilhas em horários programados.
• Cadeias de agentes de IA. Conecte LLMs às suas ferramentas internas para criar assistentes de IA personalizados capazes de pesquisar, resumir e agir sobre os seus dados.

(É nesse último caso que os recursos do seu servidor começam a pesar. Falamos mais sobre isso na seção de especificações.)

Quanto custa auto-hospedar o n8n?

A edição Community auto-hospedada não tem taxas de licenciamento nem de execução do n8n para usos permitidos. Seu custo total inclui o servidor, mais eventuais domínio, armazenamento de backup e tempo de administração. O detalhamento de custos de 2026 da ExpressTech estima uma VPS pura rodando Docker em US$ 4–5 por mês, uma VPS gerenciada pelo Coolify em US$ 5–8 e plataformas gerenciadas de n8n com um clique em US$ 3–7.

Essas são estimativas de hospedagem feitas por terceiros, no caso a ExpressTech. Agora, um número nosso: o plano que recomendamos abaixo, DreamHost VPS Hosting Stack 4, custa US$ 8,99/mês nos 3 primeiros meses com cobrança mensal. Depois disso, ele é renovado automaticamente por US$ 15,99/mês (valores de agosto de 2026), com o valor total do período mais impostos cobrado no checkout. Os preços atuais estão na página de VPS para n8n.

Compare com os planos hospedados e licenciados do próprio n8n, conforme a página de preços do n8n. O n8n cobra em euros, e estes são os valores com cobrança anual:

A diferença aumenta quando você considera como cada plataforma contabiliza o uso. O n8n cobra uma execução por execução de fluxo, regardless of complexity, e todos os planos incluem etapas ilimitadas. Já o Zapier conta cada etapa de ação bem-sucedida como uma tarefa.

Ou seja, um fluxo com quatro etapas de ação rodando 100 vezes por dia gera 3.000 execuções por mês no n8n, mas cerca de 12.000 tarefas no Zapier.

Os números reais confirmam isso. A análise da ExpressTech traz um exemplo de quatro fluxos que somam cerca de 7.000 execuções por mês. Essa carga ultrapassa o n8n Cloud Starter e exige o plano Pro (listado ali a US$ 60/mês com cobrança mensal), enquanto uma configuração auto-hospedada de US$ 3–7/mês roda tudo sem limites. Segundo a análise, a diferença fica em US$ 636–684 por ano.

Os custos ocultos da auto-hospedagem

A economia em dinheiro é real. Mas auto-hospedar não é de graça em todos os sentidos.

Veja o que isso custa para você:

Seu tempo. O tempo de manutenção varia conforme sua carga de trabalho e sua experiência operacional, mas você será responsável por atualizações, backups, monitoramento e testes de restauração. Configurações mais pesadas, com automações baseadas em IA, vão exigir mais.

Atrito na configuração do OAuth. Conectar serviços como Google Workspace ou Microsoft 365 exige configurar credenciais OAuth. Reserve um tempo extra para cada provedor e siga a documentação do console dele. (Se você já ficou olhando um ícone de carregamento enquanto uma tela de consentimento decidia se confiava no seu app, sabe como é.)

TLS em que você confia, mas verifica. O proxy Caddy da configuração abaixo obtém e renova automaticamente um certificado publicamente confiável, usando um emissor como Let’s Encrypt ou ZeroSSL. Automático não quer dizer infalível: depois de mudanças no DNS ou no proxy, confirme que o certificado continua sendo renovado.

Curva de aprendizado se você é novo em servidores. O passo a passo abaixo parte do princípio de que você sabe acessar um servidor por SSH, editar um arquivo e executar comandos. Se você nunca fez nada disso, reserve tempo para aprender, além do tempo da própria implantação.

De quais especificações de servidor o n8n precisa?

O n8n em si é leve. O mais perto de um dimensionamento oficial são os números de exemplo na documentação de implantação OEM do n8n, que o n8n descreve como for illustrative purposes only, com base no n8n Cloud: memória entre 320 MB e 2 GB, um banco de dados em SSD de 512 MB a 4 GB e cerca de 100 MB de memória para uma instância ociosa. Como alocação inicial prudente, e não como mínimo oficial do n8n, considere 2 GB para testes e 4 GB ao adicionar PostgreSQL e fluxos de produção. Monitore fluxos representativos e adicione memória quando surgir pressão constante.

Lembre também que o n8n costuma ser mais limitado pela memória do que pela CPU. A própria documentação do n8n diz isso com todas as letras: a plataforma isn’t CPU intensive, e usually, memory requirements supersede CPU requirements. O que faz a memória subir são os seus fluxos: volume de dados, nós Code (que copiam os dados antes e depois do processamento) e arquivos binários grandes.

Esta é a nossa conta de guardanapo para dimensionar a folga:

Dimensione pela concorrência de execuções e pelo volume de dados que cada fluxo processa, depois monitore o uso de memória com uma carga de trabalho representativa. Nós Code e cargas binárias grandes podem aumentar a necessidade de memória, então deixe uma folga e aumente a VPS quando o monitoramento mostrar pressão constante.

É novo em hospedagem VPS? Comece pelo guia de VPS para iniciantes da DreamHost para entender o básico antes de dimensionar seu servidor.

Qual VPS escolher para o n8n auto-hospedado?

O n8n não publica faixas fixas de RAM por carga de trabalho. Dimensione pela concorrência de execuções e pelo volume de dados, deixe folga para o Docker e o PostgreSQL, depois monitore fluxos representativos e aumente os recursos quando a pressão de memória for constante.

Veja como relacionaríamos isso aos planos da DreamHost:

Algumas especificações além da RAM merecem atenção: o n8n indica o armazenamento em SSD como boa prática para o banco de dados. A necessidade de memória costuma pesar mais que a de CPU, mas o gargalo real depende da concorrência dos fluxos de trabalho, do volume de dados e dos nós que você usa. A largura de banda ilimitada faz diferença se você roda cargas com muitos webhooks e um fluxo constante de requisições HTTP chegando.

Escolha um ambiente de hospedagem que permita rodar Docker e configurar o banco de dados, a rede, o armazenamento persistente e o proxy reverso. A hospedagem compartilhada convencional geralmente não oferece esse nível de controle.

Os planos de Hospedagem VPS da DreamHost cumprem os requisitos essenciais (armazenamento em SSD NVMe, largura de banda ilimitada, acesso root completo e suporte a Docker), e o n8n está na biblioteca de apps com um clique, pré-instalado com PostgreSQL e SSL automático, caso você prefira pular a configuração manual abaixo.

Nossa escolha para um servidor n8n com fluxos de produção é o Stack 8, o plano que nossas páginas indicam para apps em produção. O Stack 4 atende à alocação inicial de 4 GB para um primeiro servidor, mais leve. Em agosto de 2026, ele custa US$ 8,99/mês nos 3 primeiros meses com cobrança mensal e é renovado automaticamente por US$ 15,99/mês, com o valor total do período mais impostos cobrado no checkout. A página de VPS para n8n sempre mostra os preços atuais. Esse preço de renovação é o número honesto para comparar com os €20/mês do n8n Cloud Starter.

Ah, e guarde uma coisa no fundo da mente para depois: conforme seu uso cresce, o n8n oferece o modo de fila. Essa arquitetura de escalabilidade separa a instância principal (interface, gatilhos, webhooks) da execução dos fluxos, usando o Redis como intermediário de mensagens e instâncias worker para executar as tarefas. A documentação do n8n diz que esse é o modo que provides the best scalability.

Como configurar o n8n em uma VPS?

A implantação de uma instância auto-hospedada do n8n leva 11 passos: DNS, reforço do SSH, firewall, Docker, segredos, um arquivo Compose para a stack de três contêineres (n8n, PostgreSQL e Caddy), o Caddyfile, inicialização e verificação, atualizações, backups e um teste de restauração. O Caddy é o nosso proxy reverso, o servidor que fica entre a internet e a sua aplicação e cuida do TLS e do roteamento. Incluímos os comandos da implantação principal e de um teste manual de backup e restauração.

Os comandos foram feitos para o Ubuntu 22.04 ou mais recente. Quando indicado, substitua o domínio de exemplo, os valores secretos, o nome do volume e os nomes dos arquivos de backup com data. A documentação do n8n sobre Docker Compose cobre o mesmo processo com um proxy Traefik, caso você prefira seguir o modelo do próprio n8n.

O que você precisa antes de começar

• Uma VPS com acesso root rodando Ubuntu 22.04 ou mais recente, com pelo menos 2 GB de RAM (4 GB é a nossa recomendação prudente para produção)
• Um nome de domínio que você possa apontar para o endereço IP do seu servidor (para TLS e para acessar o editor do n8n)
• Familiaridade básica com o terminal — você deve saber acessar um servidor via SSH, editar um arquivo e executar comandos

Mais um pré-requisito que não aparece em nenhuma lista oficial: faça backup de N8N_ENCRYPTION_KEY assim que você gerar a chave. É por isso que, no passo 5, você cria a chave com openssl rand -hex 32 antes da primeira inicialização, em vez de deixar o n8n gerar uma silenciosamente. Essa chave criptografa todas as suas credenciais armazenadas, incluindo cada chave de API, token OAuth e senha de banco de dados que você conectou. A própria documentação do Docker do n8n avisa que, se a chave não for encontrada na inicialização, o n8n cria uma nova e as credenciais existentes não podem mais ser descriptografadas — ou seja, você vai reconstruir cada integração do zero (e se arrepender das suas escolhas de vida). Copie a chave para um lugar seguro, separado dos backups do banco de dados.

Se o seu provedor só forneceu um login root, crie primeiro um usuário de implantação, pelo console do provedor ou por uma sessão SSH como root, antes de executar os comandos SSH locais do passo 2:

adduser deploy
usermod -aG sudo deploy

Tudo a seguir é executado como esse usuário, com sudo quando necessário.

Passo 1: aponte seu domínio para o servidor

Crie um registro DNS do tipo A para um subdomínio dedicado (n8n.example.com ao longo deste guia) apontando para o endereço IP do seu servidor, exatamente como descreve o guia de Docker Compose do n8n. Faça isso primeiro: se o DNS ainda não tiver se propagado, o Caddy não consegue obter um certificado, e seu navegador pode mostrar um erro de segurança em vez do editor do n8n.

Passo 2: reforce o acesso SSH

Na sua máquina local, gere um par de chaves (a documentação do OpenSSH do Ubuntu recomenda ed25519) e copie-o para o servidor:

ssh-keygen -t ed25519
ssh-copy-id deploy@your_server_ip

Confirme que você consegue entrar com a chave. Depois, no servidor, desative o login por senha e o login como root e verifique o que o sshd vai realmente aplicar:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf > /dev/null <<'EOF'
PasswordAuthentication no
PermitRootLogin no
EOF
sudo sshd -t
sudo sshd -T | grep -E '^(passwordauthentication|permitrootlogin) '

O prefixo 00- é proposital. Segundo o manual do sshd_config, o OpenSSH usa o primeiro valor que lê para cada palavra-chave, e as imagens de servidores em nuvem costumam trazer arquivos de configuração complementares carregados antes, no mesmo diretório (o cloud-init, por exemplo, grava suas configurações de SSH em 50-cloud-init.conf). Se você der ao seu arquivo o nome 99-hardening.conf, um desses trechos pode prevalecer sem nenhum aviso. sshd -t verifica se há erros na configuração; sshd -T exibe as configurações efetivas depois que todos os arquivos são mesclados. Confirme que o último comando exibe passwordauthentication no e permitrootlogin no antes de continuar. Depois, reinicie o sshd:

sudo systemctl restart ssh.service

A documentação do Ubuntu avisa que uma configuração ruim do sshd em um servidor remoto pode deixar você trancado do lado de fora. Mantenha sua sessão atual aberta e teste um novo login em um segundo terminal antes de fechar qualquer coisa.

Passo 3: ative o firewall

O Ubuntu vem com o UFW (Uncomplicated Firewall) desativado por padrão. Libere o SSH antes de ativá-lo, para que o firewall não derrube sua própria sessão:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo ufw status

Três portas, nada mais. Um aviso específico do Docker, vindo da própria documentação de instalação do Docker: as portas que o Docker publica no host ignoram completamente as regras do UFW. É por isso que o arquivo Compose do passo 6 publica portas no host apenas para o Caddy: 80 e 443 são as únicas portas de contêiner publicadas pelo Compose (o SSH na porta 22 também fica aberto), e o n8n e o PostgreSQL não recebem nenhuma porta publicada no host.

Passo 4: instale o Docker e o Docker Compose

Instale o Docker Engine a partir do repositório apt oficial do Docker, e não pelo script de conveniência get.docker.com, que a documentação do Docker recomenda apenas para testes e desenvolvimento. Primeiro, os pré-requisitos e a chave de assinatura do Docker:

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Em seguida, registre o próprio repositório. Este comando grava o arquivo de repositório do guia de instalação do Docker para Ubuntu, preenchendo automaticamente a sua versão do Ubuntu:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Depois, instale e verifique:

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo docker run hello-world

Se o hello-world exibir a mensagem de confirmação, o Docker e o plugin do Compose estão prontos.

Passo 5: crie o diretório do projeto e os segredos

Crie o diretório do projeto e, em seguida, gere sua chave de criptografia — não deixe o n8n inventar uma silenciosamente na primeira inicialização:

sudo mkdir -p /opt/n8n-compose
cd /opt/n8n-compose
openssl rand -hex 32

Copie a saída para um lugar seguro agora mesmo — fora do servidor. Depois, coloque-a, junto com uma senha forte para o banco de dados, em um arquivo .env protegido ao lado do seu arquivo Compose (o Docker Compose o lê automaticamente). Substitua os dois valores de exemplo pelos seus:

sudo tee /opt/n8n-compose/.env > /dev/null <<'EOF'
POSTGRES_PASSWORD=choose_a_strong_password
N8N_ENCRYPTION_KEY=paste_the_64_character_key_you_just_generated
EOF
sudo chmod 600 /opt/n8n-compose/.env

O chmod 600 é importante: esse arquivo guarda segredos, então só o dono dele (root) deve conseguir lê-lo. No arquivo do Compose, N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true aplica a mesma ideia dentro do contêiner: segundo a referência de variáveis de segurança do n8n, essa opção faz o n8n tentar definir permissões 0600 no próprio arquivo de configurações.

Passo 6: escreva o arquivo do Docker Compose

Crie /opt/n8n-compose/docker-compose.yml (por exemplo, com sudo nano /opt/n8n-compose/docker-compose.yml) e cole o conteúdo a seguir, trocando n8n.example.com pelo seu próprio domínio nas duas linhas de URL e definindo seu fuso horário:

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

  n8n:
    image: docker.n8n.io/n8nio/n8n:2.36.7
    restart: unless-stopped
    expose:
      - "5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - N8N_WEBHOOK_URL=https://n8n.example.com/
      - N8N_PROXY_HOPS=1
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=America/New_York
      - TZ=America/New_York
      - EXECUTIONS_DATA_MAX_AGE=168
    depends_on:
      postgres:
        condition: service_healthy
    volumes:
      - n8n_data:/home/node/.n8n

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

volumes:
  caddy_data:
  caddy_config:
  n8n_data:
  postgres_data:

Cinco detalhes ali fazem toda a diferença:

• A imagem está fixada em uma versão específica (2.36.7 é a versão estável atual no momento em que escrevemos, segundo a documentação de instalação do n8n), então as atualizações só acontecem quando você decide.
• O n8n não publica nenhuma porta no host. Ele pode ser acessado pelos contêineres da rede do Compose, incluindo o Caddy, mas não por uma porta publicada no host. Assim, o editor só pode ser acessado pelo proxy reverso, nunca diretamente pela internet.
• O healthcheck faz o n8n esperar pelo PostgreSQL. Um depends_on simples só espera o contêiner iniciar, não que o banco de dados aceite conexões. O padrão condition: service_healthy vem direto do arquivo Compose de exemplo com Postgres do próprio n8n, que também implanta o PostgreSQL 18.
• O par N8N_WEBHOOK_URL / N8N_PROXY_HOPS é importante atrás de um proxy. Normalmente, o n8n monta as URLs de webhook a partir do protocolo, do host e da porta, e a documentação do n8n diz que isso não funciona atrás de um proxy reverso. Por isso, você define a URL de webhook manualmente para que o n8n possa register the correct webhook URLs with external services, define N8N_PROXY_HOPS como 1 e garante que o proxy repasse os cabeçalhos X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto. (A mesma página observa que N8N_WEBHOOK_URL substitui o antigo WEBHOOK_URL, descontinuado a partir do n8n 2.35.0.)
• TZ e GENERIC_TIMEZONE têm funções diferentes. Segundo a documentação do Docker do n8n, GENERIC_TIMEZONE controla nós de agendamento como o Schedule, enquanto TZ define o fuso horário do sistema do contêiner (o que comandos como date informam). Defina os dois com o mesmo valor.

(Comece com o PostgreSQL desde o primeiro dia. O padrão do n8n é o SQLite, que funciona para testes, mas os templates de hospedagem do n8n recomendam o PostgreSQL para produção, e migrar depois é doloroso, daquele jeito queria ter feito isso direito desde o começo.)

Passo 7: escreva o Caddyfile

Crie /opt/n8n-compose/Caddyfile com o seu domínio (de novo, substitua n8n.example.com):

n8n.example.com {
    reverse_proxy n8n:5678
}

Essa é toda a configuração do proxy reverso. Segundo a documentação de HTTPS automático do Caddy, o Caddy obtém e renova automaticamente um certificado publicamente confiável, usando um emissor como Let’s Encrypt ou ZeroSSL, e redireciona HTTP para HTTPS, desde que o registro A do DNS aponte para o servidor e as portas 80 e 443 estejam abertas (passos 1 e 3). O Caddy também é um dos proxies reversos usados nos exemplos oficiais de hospedagem do n8n.

Passo 8: inicie e verifique

cd /opt/n8n-compose
sudo docker compose up -d
sudo docker compose ps

Espere até que ps mostre o contêiner do postgres como saudável e o n8n em execução; depois, verifique a porta de entrada a partir de qualquer máquina:

curl -fsS -o /dev/null -w '%{http_code}' https://n8n.example.com/

Um código 2xx (ou um redirecionamento 3xx) significa que o Caddy encerrou o TLS e o n8n respondeu; se o curl terminar com erro, é sinal de que o DNS, o certificado ou os contêineres precisam de atenção (sudo docker compose logs caddy e sudo docker compose logs n8n são os primeiros lugares para verificar). Abra https://n8n.example.com em um navegador e crie sua conta de proprietário.

Passo 9: atualize o n8n com cuidado

O n8n lança uma nova versão secundária quase toda semana, e as instruções de atualização dele pedem que você confira o changelog de mudanças incompatíveis antes de atualizar. Quando estiver pronto, edite a tag de versão em docker-compose.yml e, em seguida, execute

cd /opt/n8n-compose
sudo docker compose pull
sudo docker compose up -d

Com uma tag fixada, apenas fazer pull não muda nada: você escolhe cada atualização alterando a tag, que é justamente o objetivo de fixar a versão. Faça um backup (passo 10) antes de atualizações de versão principal.

Passo 10: agende backups

Três itens são necessários para uma restauração utilizável: o banco de dados PostgreSQL, o volume n8n_data e o arquivo .env que fornece N8N_ENCRYPTION_KEY. A documentação do Docker do n8n deixa claro que, mesmo usando PostgreSQL, a pasta /home/node/.n8n (o nosso volume n8n_data) ainda guarda dados essenciais, incluindo o material da chave de criptografia. Faça backup dos três e guarde docker-compose.yml e Caddyfile para conseguir reconstruir a stack. O script abaixo cuida do banco de dados e do volume; a cópia dos arquivos de configuração para fora do servidor vem logo em seguida. Crie o script como um arquivo de propriedade do root:

sudo tee /opt/n8n-compose/backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
cd /opt/n8n-compose
STAMP=$(date +%Y-%m-%d)
mkdir -p /opt/n8n-backups
docker compose exec -T postgres pg_dump -U n8n -d n8n > "/opt/n8n-backups/n8n-db-${STAMP}.sql"
docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  tar czf "/backup/n8n-data-${STAMP}.tar.gz" -C /data .
find /opt/n8n-backups -name 'n8n-db-*.sql' -mtime +30 -delete
find /opt/n8n-backups -name 'n8n-data-*.tar.gz' -mtime +30 -delete
EOF
sudo chmod 700 /opt/n8n-compose/backup.sh
sudo /opt/n8n-compose/backup.sh

Observações sobre o script: n8n-compose_n8n_data é o nome do volume que o Compose cria para um diretório de projeto chamado n8n-compose; confirme o seu com sudo docker volume ls e ajuste se for diferente. As duas linhas find mantêm 30 dias de backups; defina outra retenção de acordo com suas necessidades de armazenamento e recuperação.

Agende-o pelo crontab do root. O cron do root só deve executar um script de propriedade do root (chmod 700, com o .env em 600), nunca um arquivo que outro usuário possa editar. Execute sudo crontab -e e adicione uma linha para uma execução diária às 3h:

0 3 * * * /opt/n8n-compose/backup.sh

O script faz backup do banco de dados PostgreSQL e do volume n8n_data de forma agendada. Copie agora o .env (que contém sua chave de criptografia) e os arquivos do Compose e do Caddy para fora do servidor, e repita sempre que eles mudarem. No servidor, crie um arquivo compactado temporário e protegido:

sudo tar -C /opt/n8n-compose -czf /home/deploy/n8n-config.tar.gz .env docker-compose.yml Caddyfile
sudo chown deploy:deploy /home/deploy/n8n-config.tar.gz
chmod 600 /home/deploy/n8n-config.tar.gz

Depois, na sua máquina local, baixe o arquivo compactado de configuração junto com os backups e apague a cópia temporária do servidor:

scp deploy@your_server_ip:/home/deploy/n8n-config.tar.gz .
scp -r deploy@your_server_ip:/opt/n8n-backups .
ssh deploy@your_server_ip 'rm /home/deploy/n8n-config.tar.gz'

Um backup que só existe no servidor que ele protege desaparece junto com o servidor.

Passo 11: teste uma restauração em uma VPS descartável

Este é um procedimento de backup e restauração para você verificar se seus backups são utilizáveis. Teste esta restauração em uma VPS de testes nova — nunca no seu servidor de produção. Provisione um servidor descartável, repita o passo 4 (Docker) nele e copie os arquivos do projeto (docker-compose.yml, Caddyfile, .env) e seus backups datados mais recentes para os mesmos caminhos.

Primeiro, troque o hostname: coloque um hostname de teste (por exemplo, n8n-restore-test.example.com, com um registro A apontando para a VPS de testes) em N8N_HOST, N8N_WEBHOOK_URL e no Caddyfile. Depois, substituindo os nomes de arquivo datados pelos seus:

cd /opt/n8n-compose
sudo docker compose create
sudo docker run --rm -v n8n-compose_n8n_data:/data -v /opt/n8n-backups:/backup alpine \
  sh -c "cd /data && tar xzf /backup/n8n-data-2026-08-25.tar.gz"
sudo docker compose up -d --wait postgres
sudo docker compose exec -T postgres psql -U n8n -d n8n < /opt/n8n-backups/n8n-db-2026-08-25.sql
sudo docker compose run --rm n8n unpublish:workflow --all
sudo docker compose up -d

A linha unpublish:workflow --all usa a CLI de servidor integrada do n8n para despublicar todos os workflows restaurados antes de a instância iniciar, para que agendamentos e gatilhos restaurados não sejam disparados contra seus sistemas de produção a partir da máquina de teste. Termine com a mesma verificação curl do passo 8, usando o hostname de teste.

Seja honesto consigo mesmo sobre o que um sinal verde significa: ele confirma que o banco de dados e o volume foram restaurados e que a stack inicia sem problemas. Ele não testa seus workflows pelo editor, então faça login na instância de teste e confira por amostragem aqueles que você não pode perder.

Como manter uma instância auto-hospedada do n8n segura?

Uma instância auto-hospedada do n8n é tão segura quanto o servidor em que ela roda, e é você quem controla esse servidor.

A segurança se resume a seis pontos. Nenhum deles é complicado isoladamente, mas pular qualquer um deixa uma brecha real. A configuração acima já implementa os três primeiros.

1. HTTPS por meio de um proxy reverso. Nunca acesse o editor do n8n por HTTP simples. A configuração do Caddy no passo 7 obtém e renova automaticamente um certificado publicamente confiável, usando um emissor como Let’s Encrypt ou ZeroSSL, e redireciona HTTP para HTTPS.
2. Firewall bem fechado. O UFW permite apenas SSH (22), HTTP (80) e HTTPS (443). Nunca exponha a porta padrão 5678 do n8n diretamente à internet. O arquivo Compose acima garante isso ao não dar ao n8n nenhuma porta publicada no host, de modo que só os contêineres da rede do Compose conseguem acessá-lo.
3. Isolamento de rede do Docker. O PostgreSQL e o n8n se comunicam pela rede interna do Compose. A porta do banco de dados nunca é publicada no host, então ela nunca pode ser acessada de fora.
4. Autenticação forte. Use uma senha forte para a conta de proprietário e ative a autenticação de dois fatores; o guia de segurança do n8n inclui a 2FA entre as proteções recomendadas para instâncias auto-hospedadas.
5. Atualizações regulares. Atualize a tag de versão no seu arquivo Compose e depois faça pull e reinicie (passo 9). Leia o changelog antes, porque as atualizações do n8n podem incluir mudanças incompatíveis.
6. Backups que você realmente restaurou. Os passos 10 e 11 trazem o agendamento e o teste. Um backup que você nunca testou é uma esperança, não um plano.

Mais um ponto de atenção que não é estritamente de segurança, mas faz uma grande diferença. Por padrão, o n8n salva a entrada e a saída de cada execução no banco de dados. A limpeza vem ativada por padrão: o n8n apaga execuções com mais de 336 horas (14 dias) ou quando você passa de 10.000 execuções armazenadas. Mesmo assim, uma instância movimentada pode inchar o PostgreSQL nesse meio-tempo.

Se seus workflows geram muitos dados, aperte essa configuração: defina EXECUTIONS_DATA_MAX_AGE=168 para limpar dados de execução com mais de sete dias (o arquivo Compose acima já faz isso) ou deixe de armazenar execuções bem-sucedidas com EXECUTIONS_DATA_SAVE_ON_SUCCESS=none.

Quais são as vantagens e desvantagens da auto-hospedagem em relação ao n8n Cloud?

Auto-hospedar o n8n oferece uma instância sem cota de execuções e com controle sobre os dados que ela armazena, pelo custo de uma VPS pequena mais a sua própria administração. O n8n Cloud elimina a manutenção de servidores, com limites de execução por plano. A escolha se resume a ser dono da sua infraestrutura de automação ou pagar para alguém rodá-la por você.

A documentação do n8n resume assim: n8n recommends self-hosting for expert users. Mistakes can lead to data loss, security issues, and downtime. If you aren’t experienced at managing servers, n8n recommends n8n Cloud.

Veja como as duas opções se comparam:

Também existe um meio-termo que vale a pena conhecer. Plataformas gerenciadas como PikaPods (cerca de US$ 3,80/mês) e Elestio (cerca de US$ 17/mês, segundo a comparação da ExpressTech) executam o n8n auto-hospedado sem que você precise gerenciar o servidor. Esses serviços podem reduzir o trabalho de administração do servidor, mas confirme quem cuida das atualizações do n8n, dos backups, do monitoramento e da segurança.

Mas vamos olhar o quadro geral. Em qualquer plano hospedado, sua capacidade de execução é uma faixa de cobrança, e é a plataforma que define as faixas. Preços, cotas e recursos podem mudar depois que você já criou seus fluxos de trabalho.

Com a auto-hospedagem, a instância e os dados que ela armazena ficam em uma infraestrutura que você controla (os serviços conectados ainda recebem tudo o que seus fluxos de trabalho enviam para eles). Controle total, responsabilidade total.

A decisão final

A auto-hospedagem faz sentido quando três condições se alinham:

1. Você executa automações suficientes para que os limites de execução da nuvem comecem a apertar
2. Você quer os dados dos seus fluxos de trabalho em uma infraestrutura que você controla
3. Você (ou alguém da sua equipe) está disposto a assumir atualizações, backups e monitoramento

Caso contrário, o n8n Cloud é uma escolha sensata. Pagar pelo plano Starter para nunca mais pensar em logs do Docker é uma troca justa, principalmente para uma equipe pequena que só quer que as automações funcionem.

Mas, quando você estiver pronto para dar o passo da auto-hospedagem, as contas logo deixam a decisão clara. Uma VPS de 4 GB é um ponto de partida prático, ainda que sem benchmarks; a capacidade em produção depende da concorrência, do volume de dados e dos nós que você usa, então monitore a instância e aumente os recursos conforme a demanda cresce. Comece pequeno, faça upgrade à medida que seus fluxos de trabalho crescem e mantenha controle total da sua stack.

Essa última parte importa mais do que parece. Você sempre pode migrar para um servidor maior. Já se desvencilhar de uma plataforma SaaS depois que ela muda os preços em cima dos fluxos de trabalho que você já criou é bem mais difícil.

Perguntas frequentes sobre a auto-hospedagem do n8n