Como hospedar o n8n por conta própria (guia 2026)

Hospedar o n8n por conta própria oferece a plataforma completa de automação de workflows, sem limites de execução e com propriedade total dos dados. Este guia percorre honestamente a configuração real com Docker, Docker Compose e PostgreSQL, e depois mostra o atalho de 30 segundos, caso você prefira pular a administração do servidor por completo.

O que significa “hospedar o n8n por conta própria”?

O n8n é uma ferramenta de automação de workflows de código disponível (source-available). Diferente do n8n Cloud, o SaaS hospedado pela equipe do n8n, hospedar por conta própria significa você rodar a aplicação n8n em infraestrutura que você controla. O software em si é gratuito sob uma licença fair-code, mas o processamento, o banco de dados, o armazenamento e a banda para mantê-lo rodando 24/7 não são. Hospedar por conta própria é a escolha certa quando você quer nenhum limite de execução, controle total sobre credenciais e dados, workflows ilimitados e a possibilidade de usar nós da comunidade e código personalizado sem um plano SaaS limitando isso.

Requisitos de sistema do n8n

O n8n é leve para começar, mas escala conforme seus workflows ficam mais pesados. Uma linha de base realista:

• CPU: 1 vCPU serve para uso leve; 2 ou mais vCPUs para muitas execuções simultâneas.
• RAM: 1 a 2 GB para o n8n. Workflows que processam payloads grandes (arquivos, imagens, JSON grande) precisam de mais.
• Banco de dados: O PostgreSQL é fortemente recomendado para produção. O SQLite padrão funciona para testes, mas não lida bem com concorrência e é mais difícil de fazer backup com segurança.
• Armazenamento: Alguns GB bastam para começar; o histórico de execuções e os dados binários crescem com o tempo.
• Rede: Um endpoint HTTPS público (porta 443) para que webhooks de entrada e callbacks de OAuth funcionem.

Para um detalhamento aprofundado mapeado para os tamanhos de plano, veja nosso guia de requisitos de servidor do n8n.

Opção 1: implante o n8n com Docker

O caminho mais rápido para rodar o n8n na sua própria máquina ou VPS é a imagem oficial do Docker. Isso é ótimo para um teste local, mas observe que ela usa SQLite e não tem TLS, então não é o que você quer em produção:

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Abra http://localhost:5678, crie a conta de proprietário e você terá um n8n funcionando. Para qualquer coisa séria, passe para o Docker Compose com PostgreSQL.

Opção 2: Docker Compose com PostgreSQL

Um setup de produção combina o n8n com um banco PostgreSQL dedicado, uma chave de criptografia e as URLs corretas de host e webhook. Salve isto como docker-compose.yml:

services:
  postgres:
    image: postgres:16
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: change-me
      POSTGRES_DB: n8n
    volumes:
      - pgdata:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: change-me
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      N8N_ENCRYPTION_KEY: a-long-random-string
    depends_on:
      - postgres
    volumes:
      - n8ndata:/home/node/.n8n

volumes:
  pgdata:
  n8ndata:

Depois execute docker compose up -d. Algumas coisas importam: defina um N8N_ENCRYPTION_KEY forte (ele criptografa suas credenciais armazenadas, então perdê-lo significa digitar de novo cada credencial), aponte WEBHOOK_URL para o seu domínio público HTTPS real e nunca exponha a porta 5678 diretamente na internet sem um reverse proxy na frente dela.

O que os tutoriais de self-hosting costumam pular

Fazer o n8n rodar é a parte fácil, os 20% iniciais. Mantê-lo rodando com segurança são os outros 80%, e é aí que uma VPS crua morde você:

• Certificados TLS: Você precisa de HTTPS para webhooks e OAuth. Isso significa Caddy, Traefik ou Nginx com Let’s Encrypt, e uma renovação de certificado que não pode falhar.
• Webhooks e reverse proxy: Webhooks de entrada exigem uma URL pública estável e cabeçalhos de proxy corretos, senão os gatilhos quebram silenciosamente.
• Backups: Seus workflows, credenciais e histórico de execução ficam no PostgreSQL. Você precisa de backups de banco automatizados e testados: um backup não testado não é um backup.
• Atualizações: O n8n é lançado com frequência. Você é responsável por baixar novas imagens, ler as notas de mudanças incompatíveis e migrar o banco de dados.
• Disponibilidade: Uma única VPS é um ponto único de falha. Se o host reiniciar às 2h da manhã, suas automações agendadas e seus webhooks param até que você perceba.

Perguntas frequentes