Se o objetivo é instalar n8n no Proxmox sem desperdiçar recursos, o caminho mais enxuto é um container LXC (CT) rodando Docker e a stack do n8n com Postgres. O passo a passo abaixo cobre tudo do zero: criação do CT, instalação do Docker, o compose completo, o primeiro acesso e uma rotina de backup em duas camadas. Sem atalho esquisito, seguindo a documentação oficial.
A versão mais recente da linha 2.x é a n8n 2.41.3, lançada em 2026-09-25 e listada no GitHub Releases do projeto. Como o n8n costuma rodar 24/7, vale montar a base do jeito certo desde o início — e isso começa na escolha do banco de dados.
Por que instalar n8n no Proxmox com CT LXC, Docker e Postgres
Containers LXC são a alternativa leve às VMs no Proxmox: usam o kernel do host, têm custo de execução praticamente nulo e, em contrapartida, só suportam distribuições Linux. Para um serviço que fica ligado o tempo todo, isso significa menos RAM e CPU gastas com sistema convidado. O Proxmox Container Toolkit (pct) é a interface oficial para criar e gerenciar esses containers, tanto via linha de comando quanto pelo wizard da interface web.
Sobre o banco: a documentação oficial é direta — SQLite serve para testes, mas instância de produção com vários usuários ou workflows rodando 24/7 deve usar Postgres, conforme o guia oficial de instalação com Docker Compose. Como a meta aqui é uma instalação de verdade, vamos direto ao Postgres.
Um detalhe do Proxmox VE: ele passou a suportar imagens OCI (application containers) como technology preview, mas para isolamento máximo e live migration a recomendação oficial ainda é nesting dentro de uma VM QEMU. Para um servidor único, o CT LXC com Docker aninhado é o equilíbrio entre leveza e simplicidade.
Passo 1: criando o CT no Proxmox
A criação pode ser feita com pct create ou pelo wizard da interface web. Para quem está começando, o wizard é mais seguro porque exibe cada opção com calma. Os pontos que exigem atenção:
- Template: baixe um template Debian pelo próprio Proxmox e use como base do CT;
- Recursos: para um uso leve, 2 vCPU e 2 GB de RAM costumam dar conta — trate como ponto de partida, não como regra oficial;
- Nesting: nas opções de features do CT, ative o recurso de nesting — sem ele o Docker não funciona dentro do LXC;
- IP fixo: configure um endereço estático na rede do CT, para o n8n sempre responder no mesmo lugar;
- Início automático: a opção onboot vem com padrão 0; mude para 1 e o container sobe junto com o boot do host, o que faz o n8n voltar sozinho depois de uma queda de energia.
Se algum campo do wizard ficar dúvida, a wiki oficial do Proxmox detalha cada opção de criação de container.
Passo 2: instalando o Docker e o Docker Compose no CT
Com o CT criado e ligado, acesse o console dele pelo Proxmox ou por SSH. A instalação do Docker no Debian deve seguir o guia oficial publicado em docs.docker.com — lá existe um passo a passo específico para Debian, incluindo o plugin do Docker Compose. Evite copiar comandos de fontes aleatórias, porque o repositório correto importa.
Depois de instalar, teste baixando a imagem oficial do n8n, exatamente como recomendado no Docker Hub:
docker pull docker.n8n.io/n8nio/n8n
Esse comando puxa a tag latest estável. No próximo passo, em vez de latest, vamos fixar a tag da versão no compose — em produção, saber exatamente o que está rodando evita surpresa.
Passo 3: o docker-compose.yml do n8n com Postgres
A instalação oficial com Docker usa a imagem n8nio/n8n, o volume n8n_data montado em /home/node/.n8n e a porta 5678. O exemplo oficial de compose usa o serviço postgres com a imagem postgres:18, PGDATA em /var/lib/postgresql/data e um volume dedicado chamado db-storage. Seguindo esse padrão, o arquivo fica assim:
services:
postgres:
image: postgres:18
environment:
- POSTGRES_USER=n8n
- POSTGRES_PASSWORD=suasenha
- POSTGRES_DB=n8n
- PGDATA=/var/lib/postgresql/data
volumes:
- db-storage:/var/lib/postgresql/data
n8n:
image: docker.n8n.io/n8nio/n8n:2.41.3
ports:
- "5678:5678"
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=suasenha
- DB_POSTGRESDB_SCHEMA=public
- GENERIC_TIMEZONE=America/Sao_Paulo
- TZ=America/Sao_Paulo
- N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
- N8N_RUNNERS_ENABLED=true
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:
db-storage:
Antes de subir, troque suasenha nos dois serviços — o valor precisa ser idêntico no Postgres e na variável DB_POSTGRESDB_PASSWORD do n8n. O exemplo oficial na documentação inclui variações desse arquivo, caso queira comparar depois.
| Variável | O que faz |
|---|---|
DB_TYPE=postgresdb | Ativa o Postgres como banco do n8n. |
DB_POSTGRESDB_HOST e DB_POSTGRESDB_PORT | Apontam para o serviço postgres do compose. |
DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER e DB_POSTGRESDB_PASSWORD | Definem o banco e as credenciais de conexão. |
DB_POSTGRESDB_SCHEMA | Schema dentro do banco; o exemplo usa public. |
GENERIC_TIMEZONE e TZ | Controlam o fuso horário da instância. |
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true | Reforça permissões do arquivo de configuração; faz parte da recomendação oficial. |
N8N_RUNNERS_ENABLED=true | Habilita os runners; também recomendado na instalação oficial. |
A tag 2.41.3 é a versão mais recente listada no GitHub Releases. Fixar a tag em vez de usar latest dá controle sobre o momento da atualização — tema da seção final.
Passo 4: subindo a stack, criando a conta owner e ajustando fuso
Com o arquivo salvo, suba a stack de dentro do diretório do projeto:
docker compose up -d
Em seguida, acesse http://IP-DO-CT:5678 pelo navegador. No primeiro acesso, o n8n pede a criação da conta owner — defina um e-mail e uma senha fortes, porque essa conta controla a instância inteira.
O fuso horário já vem resolvido no compose: GENERIC_TIMEZONE e TZ apontam para America/Fortaleza no exemplo. Se a sua instância servir outra região, ajuste os dois valores — agendamentos e triggers baseados em horário dependem disso para disparar no momento certo.
Passo 5: backup em duas camadas (pg_dump + vzdump)
Uma camada só não é backup de verdade. A primeira camada protege os dados: um export do Postgres com pg_dump, rodando com a stack no ar.
docker compose exec postgres pg_dump -U n8n n8n > backup-n8n.sql
Coloque esse comando em uma rotina (por exemplo, no cron do CT) e guarde o arquivo fora do container — de preferência fora do próprio host. É o backup que salva quando alguém apaga um workflow por engano.
A segunda camada protege o CT inteiro: o vzdump, ferramenta de linha de comando do Proxmox executada no host, não dentro do CT. Em modo snapshot, o container continua rodando durante o backup, e a restauração pode ser feita com pct restore:
vzdump <vmid> --mode snapshot
Confira as opções completas de vzdump e pct restore na wiki oficial do Proxmox antes de automatizar, porque os modos e destinos de armazenamento variam conforme o ambiente.
Problemas comuns e como resolver
- Docker não sobe dentro do CT: nesting desativado nas features do container — volte nas opções do CT e ative;
- n8n não conecta ao Postgres: confira as variáveis DB_POSTGRESDB_* e se a senha é idêntica nos dois serviços;
- Agendamentos disparando no horário errado: revise GENERIC_TIMEZONE e TZ no compose;
- CT não volta depois de queda de energia: a opção onboot provavelmente continua em 0;
- Dados somem ao recriar os containers: os volumes n8n_data e db-storage precisam estar declarados no compose, como no exemplo.
Como atualizar o n8n com segurança e próximos passos
O n8n lança uma nova versão minor na maioria das semanas, e a linha stable é a recomendada para produção. Um detalhe que confunde: o changelog oficial chegou a listar stable 2.40.5 e beta 2.41.1 enquanto o GitHub já tinha a 2.41.3 — em caso de divergência, vale o GitHub Releases.
A rotina segura de atualização começa com um pg_dump atualizado. Depois, com a nova tag escrita no compose:
docker compose pull
docker compose up -d
Com o CT leve, o Postgres no lugar do SQLite e o backup em duas camadas, a base está pronta para uso sério. Como próximos passos, estudar na documentação oficial do n8n a parte de HTTPS e proxy reverso antes de expor a instância para fora da rede local.
Perguntas frequentes
SQLite não serve para nada?
Serve para testes e avaliações. Para produção com vários usuários ou workflows rodando 24/7, a documentação oficial do n8n recomenda Postgres.
Como faço o n8n voltar sozinho depois de uma queda de energia?
Ative a opção onboot do CT no Proxmox. Ela vem desligada por padrão e controla se o container inicia junto com o boot do host.
É possível fazer backup sem parar o n8n?
Sim. O vzdump em modo snapshot roda com o CT ligado, e o pg_dump exporta o banco com a stack no ar.