Quanta RAM o n8n auto-hospedado precisa?

Cerca de 2 GB é o ponto ideal confortável para o n8n mais o banco de dados Postgres e fluxos normais. Ele roda em 1 GB se os fluxos são leves, mas você vai sentir durante rodadas maiores. Execuções paralelas pesadas ou payloads grandes — vá para 4 GB.

Preciso de Docker para auto-hospedar o n8n?

É de longe a forma mais fácil — um arquivo compose te dá o n8n, um banco de dados e armazenamento persistente, e as atualizações são um único pull. Você pode instalar via npm em vez disso, mas o Docker te poupa as dores de cabeça de dependência e atualização.

Auto-hospedar o n8n é mais barato que o n8n cloud?

Se você roda um fluxo constante de automações, sim — um VPS mensal fixo bate o preço por execução, e não há limite de fluxos ou execuções. Para um punhado de rodadas por mês, um assento hospedado pode ser mais simples. A outra razão pela qual as pessoas auto-hospedam é o controle: seus dados e chaves de API nunca saem do seu servidor.

Preciso de um domínio para o n8n?

Para nós baseados em OAuth (Google, etc.) e HTTPS limpo, sim — aponte um domínio para o servidor e coloque o n8n atrás de um reverse proxy com um certificado. Para uso puramente interno você pode alcançá-lo por um túnel SSH sem um domínio.

O n8n pode rodar num VPS NAT ou preciso de um IP dedicado?

Uso interno/túnel SSH funciona numa máquina NAT. Se você quer uma URL pública com o seu próprio domínio e HTTPS (necessário para alguns callbacks de OAuth e webhooks), um plano com IP dedicado é o encaixe mais limpo já que você controla todas as portas.

Auto-hospede o n8n num VPS com Docker

O n8n é o tipo de ferramenta que você começa usando de leve e depois silenciosamente roteia metade das suas operações por ela. Nesse ponto "está rodando no assento de nuvem de alguém, medido por execução, com minhas chaves de API morando nos servidores deles" começa a parecer menos ótimo. Auto-hospedar conserta os três — custo fixo, sem limite de execução e suas chaves ficam numa máquina que você possui. Com o Docker é um trabalho de quinze minutos.

Quanto servidor ele de fato precisa

Números honestos primeiro, para você não comprar demais nem de menos:

~2 GB de RAM é o ponto ideal — o n8n mais o banco Postgres mais fluxos normais ficam confortáveis aqui.
1 GB funciona se seus fluxos são leves, mas você vai notar em rodadas maiores.
4 GB se você faz execuções paralelas pesadas ou empurra payloads grandes.

O n8n não é faminto por CPU em repouso; ele dá picos durante as rodadas. Uma máquina de 2 núcleos serve para a maioria dos setups. (Mais sobre combinar specs com carga no guia de dimensionamento.)

O setup com Docker

Numa máquina Ubuntu/Debian nova, instale o Docker:

curl -fsSL https://get.docker.com | sudo sh

Crie uma pasta e um docker-compose.yml — n8n com um volume persistente e Postgres:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - N8N_HOST=n8n.seudominio.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.seudominio.com/
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=db
      - DB_POSTGRESDB_PASSWORD=change-me
    volumes:
      - ./n8n-data:/home/node/.n8n
    depends_on: [db]
  db:
    image: postgres:16
    restart: always
    environment:
      - POSTGRES_PASSWORD=change-me
      - POSTGRES_DB=n8n
    volumes:
      - ./db-data:/var/lib/postgresql/data

sudo docker compose up -d

Duas coisas que vale apontar: os volumes (n8n-data, db-data) são o que mantêm seus fluxos vivos entre reinícios e atualizações — não os pule. E o n8n está vinculado a 127.0.0.1, não a 0.0.0.0 — ele não está exposto à internet diretamente. Isso é deliberado; o próximo passo cuida do acesso com segurança.

Acesso: HTTPS ou um túnel

URL pública (necessária para nós OAuth e webhooks): aponte um subdomínio para o servidor e rode um reverse proxy (o Caddy é o de menor esforço — HTTPS automático) na frente de 127.0.0.1:5678. É aqui que um plano com IP dedicado encaixa, já que você controla portas e DNS.
Só para você, sem domínio: pule o proxy e alcance-o por um túnel SSH — ssh -L 5678:127.0.0.1:5678 user@server, depois abra localhost:5678. Funciona bem num VPS NAT.

Tranque e mantenha de pé

O n8n guarda suas chaves de API e credenciais, então a máquina precisa estar firme: faça o checklist de segurança (chaves SSH, firewall, sem login por senha) antes de colocar credenciais de verdade. restart: always no arquivo compose já significa que o Docker traz o n8n de volta após uma queda ou reboot — esse é o seu uptime resolvido.

Vale a pena?

Seja honesto consigo mesmo sobre volume. Se você roda automações constantemente, auto-hospedar vence no custo (fixo vs por execução) e remove qualquer limite de fluxo/rodada. Se você dispara alguns fluxos por mês, um assento hospedado dá menos trabalho. Mas o argumento do controle vale de qualquer forma: seus fluxos, seus dados, suas chaves — no seu servidor, não alugados. Para a maioria das pessoas que ficaram sérias com o n8n, esse é o fator decisivo.

Uma máquina de 2 GB, um arquivo compose, um domínio (ou um túnel), e você está rodando o seu próprio hub de automação — pagável em cripto sem KYC, no ar em minutos.

Setup pronto: veja VPS para n8n — o plano recomendado e um deploy em cripto de um minuto.