Hospede o n8n num servidor de US$6

Toda ferramenta de automação de workflow que cobra por execução transforma “conectar essas duas APIs” num custo recorrente que cresce exatamente com a coisa que você automatizou para parar de pensar nela. O n8n faz o mesmo trabalho que Zapier ou Make, workflows visuais que chamam APIs sem você escrever e manter código de ligação, como software open-source que você mesmo roda. No final deste guia, você vai ter sua própria instância do n8n rodando num servidor de US$6/mês, acessível via HTTPS no seu próprio domínio, apoiada em Postgres em vez de um único arquivo SQLite, com backups e um caminho de upgrade que não quebra na sua mão.

O que você vai precisar

• Um servidor. O Basic Droplet da DigitalOcean por US$6,00/mês te dá 1 vCPU, 1 GB de RAM e 25 GB de SSD, o que é suficiente para o n8n, o Postgres e um proxy reverso rodando juntos numa única máquina para uso pessoal ou de equipe pequena. Qualquer VPS Ubuntu 24.04 de outro provedor funciona da mesma forma.
• Um domínio (ou um subdomínio de um que você já tenha), com acesso às configurações de DNS dele.
• Docker e o plugin Docker Compose instalados no servidor (coberto na Etapa 2).
• Um terminal e acesso SSH ao servidor.

Etapa 1: Crie o servidor e aponte um domínio para ele

Suba um droplet Ubuntu 24.04 no plano Basic de US$6/mês da DigitalOcean (1 vCPU, 1 GB de RAM, 25 GB de SSD). Anote o IP público dele.

Nas configurações de DNS do seu domínio, adicione um registro A apontando um subdomínio, por exemplo n8n.yourdomain.com, para esse IP:

Type: A
Name: n8n
Value: <IP do seu servidor>
TTL: 300

A propagação do DNS pode levar de alguns minutos a algumas horas. Você deve ver dig n8n.yourdomain.com +short retornar o IP do seu servidor antes de continuar, já que as próximas etapas dependem disso.

Etapa 2: Instale o Docker

Conecte via SSH ao servidor e instale o Docker Engine mais o plugin Compose:

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER

Saia e entre de novo para a mudança de grupo ter efeito, depois confira que as duas peças estão presentes:

docker --version
docker compose version

Você deve ver uma versão do Docker e uma versão do Compose impressas, sem erros de “command not found”.

Etapa 3: Organize o projeto e seus segredos

Crie um diretório para a stack e um arquivo .env para guardar tudo que não deveria viver no próprio arquivo compose:

mkdir -p ~/n8n && cd ~/n8n

Gere uma chave de criptografia real. O n8n usa isso para criptografar cada credencial guardada no banco de dados, então perder essa chave significa perder acesso a toda credencial salva, não só desta instalação:

openssl rand -base64 32

Crie o .env com essa chave, seu domínio, um timezone e uma senha de banco de dados:

# .env
DOMAIN=n8n.yourdomain.com
GENERIC_TIMEZONE=America/New_York
N8N_ENCRYPTION_KEY=<cole a chave que você acabou de gerar>
POSTGRES_USER=n8n
POSTGRES_PASSWORD=<uma senha longa e aleatória>
POSTGRES_DB=n8n

Defina as permissões para que só o seu usuário possa lê-lo:

chmod 600 .env

Etapa 4: Escreva o arquivo Docker Compose

O n8n vem com um banco de dados SQLite por padrão, que é bom para experimentar, mas não para uma instância que roda o tempo todo com mais do que um punhado de workflows. Postgres é o banco de dados que o próprio n8n recomenda depois que você passa da fase de “só testando”, então esta configuração usa ele desde o início.

Crie o docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:1.68.0
    restart: unless-stopped
    environment:
      - N8N_HOST=${DOMAIN}
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - N8N_WEBHOOK_URL=https://${DOMAIN}/
      - N8N_PROXY_HOPS=1
      - N8N_RUNNERS_ENABLED=true
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - n8n-net

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

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DOMAIN=${DOMAIN}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config
    depends_on:
      - n8n
    networks:
      - n8n-net

networks:
  n8n-net:

volumes:
  n8n_data:
  postgres_data:
  caddy_data:
  caddy_config:

Algumas escolhas que valem explicar:

• A imagem do n8n está fixada em 1.68.0 em vez de latest. Uma ferramenta de automação que faz upgrade de si mesma silenciosamente num restart do servidor, levando seus workflows junto para o que quer que tenha mudado, não é uma boa troca. Você faz upgrade na sua própria agenda, coberto na Etapa 7.
• N8N_PROXY_HOPS=1 e N8N_WEBHOOK_URL importam porque o n8n fica atrás do Caddy aqui em vez de exposto direto à internet. Sem eles, o n8n não sabe seu próprio endereço HTTPS público e registra URLs de webhook erradas com serviços externos.
• N8N_RUNNERS_ENABLED=true ativa o task runner do n8n, que executa scripts de nó Code num processo isolado em vez de dentro do próprio processo principal do n8n. Pular isso numa release 1.x significa que qualquer script num nó Code roda sem isolamento nenhum, o que importa no momento em que você está rodando workflows que você não escreveu.
• Só o Caddy publica portas no host. O n8n e o Postgres só são acessíveis pela rede interna do Docker, não diretamente pela internet.

Etapa 5: Escreva o Caddyfile e inicie tudo

O Caddy cuida do certificado TLS do Let’s Encrypt automaticamente, desde que o DNS já esteja apontando para o servidor e as portas 80 e 443 estejam acessíveis pela internet. Crie o Caddyfile no mesmo diretório:

{$DOMAIN} {
	reverse_proxy n8n:5678
}

Inicie a stack:

docker compose up -d

Observe ela subir e confira se o Caddy de fato obteve um certificado:

docker compose logs -f caddy

Você deve ver uma linha mencionando um certificado obtido para o seu domínio, e então acessar https://n8n.yourdomain.com num navegador deve carregar a tela de configuração do n8n com um cadeado válido, sem aviso de certificado. Crie sua conta de dono lá; isso é o próprio fluxo de primeira execução do n8n, não algo que esta stack configura para você.

Etapa 6: Faça backup dos workflows, credenciais e da chave de criptografia

Três coisas precisam de backup: o banco Postgres (seus workflows, execuções e credenciais), o volume n8n_data (o estado local do próprio n8n, incluindo qualquer coisa que não está no banco de dados), e o arquivo .env (sua chave de criptografia, sem a qual as credenciais naquele banco ficam ilegíveis).

Um dump diário do Postgres, mantido fora do servidor:

docker compose exec -T postgres pg_dump -U n8n n8n > "n8n-backup-$(date +%F).sql"

Coloque isso num cron job e copie o resultado para algum lugar fora deste servidor, um bucket de object storage, outra máquina, qualquer lugar que não seja este droplet. Um backup que vive só no servidor que ele está protegendo não sobrevive ao tipo de falha que de fato destrói um servidor.

Para o volume e o arquivo .env:

docker run --rm -v n8n_n8n_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/n8n-data-backup.tar.gz -C /data .
cp .env ~/n8n-env-backup-$(date +%F)

Guarde esse backup do .env em algum lugar separado e com acesso controlado; ele contém tanto a senha do seu banco de dados quanto sua chave de criptografia.

Etapa 7: Faça upgrade do n8n sem surpresas

Confira a versão que você está rodando atualmente, leia as release notes do n8n sobre qualquer coisa entre essa versão e a que você vai migrar, depois mude a tag no docker-compose.yml:

image: n8nio/n8n:1.69.0

Baixe a imagem e reinicie só esse serviço:

docker compose pull n8n
docker compose up -d n8n

Você deve ver os logs do n8n mostrarem uma inicialização limpa sem erro de migração de banco de dados falhada, e seus workflows existentes devem continuar lá quando você fizer login de novo. Se uma migração de fato falhar, seu backup do Postgres da Etapa 6 é o caminho de volta para a versão anterior.

O caminho curto: faça com o Railyard

Tudo isso acima, um n8n apoiado em Postgres com uma chave de criptografia gerada, um volume de dados persistente, e HTTPS já ligado, também é um template de um clique:

https://app.railyard.run/deploy?template=n8n

Esse template de container único é o encaixe certo para o mesmo caso que a configuração manual acima cobre: um usuário ou uma equipe pequena rodando automação interna. Se depois você crescer além disso, rodando volume de workflow suficiente para a entrega de webhook e a execução começarem a competir pelo mesmo processo, a própria arquitetura de modo de fila do n8n separa esses dois trabalhos, e isso está disponível como uma stack separada: escolha n8n (queue mode) no catálogo de templates em vez de fazer o deploy direto por um link, já que uma stack precisa que você confirme os serviços dela primeiro. Ela roda os processos web e worker do n8n contra o próprio Postgres e um Redis protegido por senha para a fila de jobs.

Se você preferir começar pelo Railyard de forma geral antes de decidir pelo n8n especificamente, o quickstart cobre o básico, e databases and backups explica como os backups funcionam em todos os templates, não só este. Deploy button cobre o próprio formato do link ?template= se você quiser incorporar um em outro lugar. Para uma comparação mais ampla do que um droplet de US$6 de fato te dá contra uma alternativa gerenciada, veja hosting costs.

Solução de problemas

O Caddy nunca obtém um certificado, ou o navegador mostra um aviso de certificado. Isso quase sempre é DNS, não o Caddy. Rode dig n8n.yourdomain.com +short da sua própria máquina e confirme que retorna o IP do servidor, não um antigo, e não nada. O Let’s Encrypt também precisa que a porta 80 esteja acessível pela internet para a validação inicial, então confira se o firewall ou security group do seu provedor de nuvem permite entrada nas portas 80 e 443, não só a 443.

docker compose up falha com “port is already allocated”. Alguma outra coisa na máquina já está vinculada à porta 80 ou 443, geralmente uma instalação padrão de Nginx ou Apache. Encontre com sudo ss -tlnp | grep -E ':80|:443' e pare esse serviço, ou mude quais portas o Caddy publica se você genuinamente precisa dos dois rodando.

Os logs do n8n mostram URLs de webhook apontando para o endereço errado, ou para http em vez de https. Confira se N8N_HOST, N8N_PROTOCOL e N8N_WEBHOOK_URL no arquivo compose correspondem ao seu domínio real e a https, e se N8N_PROXY_HOPS=1 está definido. Sem ele, o n8n não confia nos cabeçalhos repassados que o Caddy está enviando e volta a adivinhar seu próprio endereço.

O container do Postgres fica reiniciando, ou o n8n não consegue conectar ao banco. Confira docker compose logs postgres primeiro para ver o erro real. Um POSTGRES_PASSWORD que não bate entre o serviço Postgres e o DB_POSTGRESDB_PASSWORD que o n8n está usando para conectar é a causa mais comum, geralmente por editar o .env depois que o volume do Postgres já foi inicializado com a senha antiga; o Postgres só lê essas variáveis de ambiente na primeiríssima inicialização com um diretório de dados vazio.

O container inicia e sai imediatamente, ou o volume mostra erros de permissão. Isso geralmente aparece se você monta via bind um diretório do host em vez de um volume nomeado do Docker para /home/node/.n8n. A imagem do n8n roda como um usuário não root, e um diretório do host criado pelo root não vai ser gravável por ele. Volumes nomeados, como usados no arquivo compose acima, evitam isso completamente porque o Docker gerencia a propriedade deles.

O servidor fica sem memória sob carga real. Um droplet de 1 GB rodando n8n, Postgres e Caddy juntos tem pouca folga. Adicione um arquivo de swap como amortecedor (fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile), e se você estiver rodando workflows que processam payloads grandes ou muitas execuções simultâneas, suba para um droplet de 2 GB em vez de depender do swap como correção permanente.

Perguntas frequentes

Eu preciso de Postgres, ou SQLite é suficiente? O SQLite, padrão do n8n, funciona para experimentar, mas não lida bem com mais do que um punhado de workflows simultâneos e não é o que o n8n recomenda depois que uma instância passa a ser de fato usada. Postgres desde o início, como neste guia, evita uma migração mais tarde.

Posso rodar isso sem um domínio, só com o IP do servidor? O HTTPS automático do Caddy precisa de um domínio real; o Let’s Encrypt não emite certificados para endereços IP simples. Você pode rodar via HTTP puro num IP para testes rápidos, apontando um navegador direto para a porta 5678, mas não guarde credenciais reais numa instância que não está atrás de HTTPS.

Quanto isso de fato custa para rodar? O servidor custa US$6/mês. O n8n em si é software livre e gratuito sem limites próprios de execução; você está pagando pela máquina em que ele roda, não pelo que roda nela.

O que acontece com meus workflows se eu perder a chave de criptografia? Toda credencial que o n8n guardou fica ilegível. A estrutura dos workflows sobrevive, mas qualquer coisa que precisava de uma chave de API ou token OAuth salvo vai precisar que essas credenciais sejam digitadas de novo. Esse é todo o motivo da Etapa 6 fazer backup do .env separadamente do banco de dados.

A configuração de container único aqui é a mesma coisa que o template de n8n do Railyard roda? Quase, com uma diferença real: o template do Railyard não inclui o Postgres por padrão, já que a maioria das instalações de um único usuário não precisa dele desde o primeiro dia. A arquitetura, um container de n8n com uma chave de criptografia gerada e um volume de dados persistente, é a mesma ideia; este guia adiciona o Postgres porque é o padrão mais honesto para qualquer coisa que você pretenda manter rodando.

Qualquer um dos dois caminhos te dá a mesma coisa no final: seu próprio servidor de automação, seus próprios dados, e uma conta que não muda quando seus workflows fazem mais trabalho.