Pular para o conteúdo
EntrarCriar minha VPS

n8n não inicia: erros comuns e soluções

Se o n8n não inicia depois de um restart, na maioria dos casos o container do PostgreSQL sobe antes do n8n estar pronto, ajuste o depends_on para usar condition: service_healthy. Outros candidatos comuns são a porta 5678 ocupada por outro processo, uma variável de ambiente ausente ou o volume com permissão incorreta.

Diagnóstico rápido: veja os logs primeiro

Antes de tentar qualquer correção, verifique o que o container está reportando. Os logs revelam a causa em quase todos os casos:

bash
# Últimas 50 linhas de log do container n8n
docker compose logs n8n --tail=50

# Status de todos os containers do stack
docker compose ps

Causa 1: PostgreSQL sobe depois do n8n (o mais comum)

O n8n tenta se conectar ao banco logo ao iniciar. Se o PostgreSQL ainda não terminou o startup, o n8n recebe ECONNREFUSED e encerra. A solução é usar depends_on com condition: service_healthy, que força o Docker a aguardar o healthcheck do postgres passar antes de iniciar o n8n:

yaml
services:
  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: sua_senha
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 5s
      timeout: 5s
      retries: 5
    volumes:
      - postgres_data:/var/lib/postgresql/data

  n8n:
    image: n8nio/n8n:latest
    restart: always
    ports:
      - "5678:5678"
    depends_on:
      postgres:
        condition: service_healthy   # aguarda o healthcheck passar
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=sua_senha

volumes:
  postgres_data:

Causa 2: porta 5678 já está em uso

Se outro processo já ocupa a porta 5678, o n8n falha ao tentar fazer bind. O log mostrará address already in use ou EADDRINUSE.

bash
# Verificar qual processo está usando a porta 5678
ss -tlnp | grep 5678

# Alternativa com lsof
lsof -i :5678

Causa 3: variável de ambiente ausente ou inválida

Variáveis incorretas são silenciosas, o n8n tenta iniciar, não consegue conectar ao banco e encerra sem mensagem clara. Inspecione a configuração resolvida antes de subir:

bash
# Mostrar a configuração final com variáveis expandidas
docker compose config

Causa 4: permissão incorreta no volume

O n8n roda internamente como UID 1000. Se o diretório de bind mount pertence a root, o processo não consegue gravar e para na inicialização.

bash
# Corrigir permissões no diretório local (bind mount)
chown -R 1000:1000 ./n8n_data

# Se usar volume nomeado, recrie o container
docker compose down
docker compose up -d

Causa 5: memória insuficiente

O n8n precisa de pelo menos 512 MB de RAM livre para iniciar. Com workflows ativos, use 1 GB ou mais. Verifique o consumo atual:

bash
# Memória disponível no sistema
free -h

# Consumo por container
docker stats --no-stream

Como reiniciar o n8n com segurança

Após corrigir a causa raiz, use o comando adequado para reiniciar sem impactar o banco:

bash
# Reiniciar apenas o n8n (mantém postgres e Redis rodando)
docker compose restart n8n

# Reiniciar tudo — necessário após editar o docker-compose.yml
docker compose down
docker compose up -d

# Confirmar que o container está saudável
docker compose ps

Não quer configurar manualmente?

Implante o n8n em menos de 5 minutos com a Runstack. Infraestrutura da OPEN Datacenter, com servidores em São Paulo.

Criar minha VPSVer apps prontos

Perguntas frequentes

Provavelmente o container não tem restart: always configurado. Sem essa diretiva, o Docker não reinicia os containers após reboot do sistema. Adicione restart: always ao serviço n8n no docker-compose.yml e recrie o container com docker compose up -d.

Use docker compose logs n8n --tail=100 -f para exibir as últimas 100 linhas e continuar monitorando em tempo real. Para ver logs de um container pelo ID: docker logs <id-do-container>.

Verifique localmente com curl http://localhost:5678. Se responder localmente mas o navegador não acessa, o firewall da VPS pode estar bloqueando a porta. Libere com ufw allow 5678 ou pelo painel da Runstack.

Use docker compose restart n8n, ele reinicia apenas o serviço n8n, mantendo postgres, redis e outros containers em execução. Isso é mais rápido e não gera downtime de banco.

Isso acontece quando o PostgreSQL subiu, mas o usuário/banco do n8n não foram criados (ocorre geralmente na primeira execução com banco novo). Destrua o volume e recrie: docker compose down -v && docker compose up -d. Atenção: -v apaga os dados do banco, faça backup antes.

Continue lendo