Descreva o problema/erro/pergunta
Existem dois documentos diferentes explicando como configurar o n8n com Docker Compose:
e as configurações são muito diferentes.
Qual deles devo seguir?
Oi @Daniel, enquanto você aguarda uma resposta, aqui estão algumas coisas que podem ajudar:
Recursos sugeridos
Correspondência automática com sua pergunta.
Docs:
Fórum:
@Zelite - você já ajudou com problemas semelhantes antes, pode dar uma olhada?
Sugerido automaticamente pelo bot da comunidade n8n. É um piloto - compartilhe seus comentários aqui.
Oi @Daniel
Ambos são atuais, apenas resolvem problemas diferentes.
- Use Docker Compose, o que está em use-a-cloud-provider, é o guia de implantação do servidor. n8n mais Traefik, então você obtém um domínio, certificados Let’s Encrypt automáticos e HTTPS. Ele cobre a configuração de DNS e espera um VPS Linux. Sem Assistente de IA.
- Instalar usando Docker Compose é o mais novo, construído em torno da pilha de sandbox do Assistente de IA. Cinco serviços, precisa de 4GB de RAM e 2 vCPUs, e Docker in Docker para o executor de sandbox. Sem proxy reverso, então é servido em localhost:5678 sem TLS.
Qual seguir depende do que você quer. Servidor público com um domínio, pegue o primeiro. Máquina local e você quer o Assistente de IA, pegue o segundo.
Nenhum inclui Postgres por padrão, ambos recuam para SQLite. Vale a pena adicionar para qualquer coisa além de testes, a segunda página tem o bloco para isso.
Oi @Daniel
A configuração em uma linha gera a segunda pilha para você, compose.yml, searxng-settings.yml e .env com segredos únicos já preenchidos, então escrever manualmente esses arquivos só é necessário se você quiser personalizar a configuração ou integrar o n8n em um projeto Compose existente:
curl -fsSL https://get.n8n.io | sh -s -- --version 2.35.0
O pinning de versão continua necessário até que 2.35.0 saia de beta para estável.
Se você estiver seguindo a rota do servidor, isso cobre dimensionamento e escolha de provedor:
E quanto aos que querem os dois? 
Acho que vou combiná-los em um único arquivo compose.yml. Já tenho o Nginx rodando fora do container, então vou omitir o Traefik.
Não gosto de scripts de configuração porque não confio que eles não vão bagunçar minha configuração existente, e prefiro escrever meu compose.yml na mão para entender como tudo está configurado. Mas vou dar uma olhada no que o script faz.
Já tenho um VPS com 10GB de RAM e 100GB de NVMe que está rodando apenas Odoo e Swetrix no momento, então deve ficar bem. Se eu tiver algum problema, vou mover para um dos meus sistemas com 16GB de RAM 
A combinação já está documentada. Os guias do DigitalOcean e Hetzner usam um n8n com reverse-proxy e a stack sandbox adicionada no topo, então você pode extrair os serviços sandbox diretamente de lá em vez de mesclar os dois arquivos Compose você mesmo. O proxy apenas roteia o n8n, os serviços sandbox permanecem internos à rede Compose e não precisam de alterações de DNS ou firewall, então remover o Caddy em favor do seu Nginx externo não custa nada lá. Vale a pena saber antes de colocar na mesma máquina que o Odoo: sandbox-runner-1 é um Docker-in-Docker privilegiado e é efetivamente root no host, e Daytona é o provedor sandbox recomendado para uma implantação real.
A única coisa que nenhuma página cobre para um proxy fora do Docker: N8N_HOST mais N8N_PROTOCOL não vão construir a URL do webhook certa, já que n8n funciona na porta 5678 internamente enquanto Nginx responde na 443. Defina estas no serviço n8n e passe X-Forwarded-For, X-Forwarded-Host e X-Forwarded-Proto do Nginx:
N8N_WEBHOOK_URL=https://n8n.example.com/
N8N_PROXY_HOPS=1
N8N_WEBHOOK_URL substitui WEBHOOK_URL, que a página do Traefik ainda usa e que agora registra um aviso de descontinuação.
Acabei de ver que o script baixa o compose.yml de https://raw.githubusercontent.com/n8n-io/n8n/master/docker/get-n8n-compose.yml. Posso usar isso como base e simplificar (ou estender) conforme minhas necessidades. Obrigado!
Descobri ao avaliar o n8n que preciso tanto de N8N_WEBHOOK_URL quanto de N8N_EDITOR_BASE_URL, porque quero usar URLs diferentes para webhooks (publicamente acessível) versus o editor n8n em si (acessível apenas através de uma VPN).
O último foi difícil de descobrir, já que não conseguia vê-lo na documentação. Talvez eu tenha perdido a página correta.
Bom ponto — não tinha percebido isso. Vou colocar em uma VM isolada.
Isso significa que sysbox ou daytona não são mais necessários?
Anteriormente isso era obrigatório
Tendo dificuldades com sysbox no Oracle Linux antes disso
@kjooleng nenhum deles é necessário para a stack que o guia do Compose constrói. Ele executa sandbox-runner-1 como Docker-in-Docker simples com privileged: true, sem sysbox-runc e sem chaves Daytona, então funciona no Oracle Linux onde sysbox não será instalado. A página do AI Assistant lista três configurações agora, a sandbox agrupada da configuração de uma linha, a mesma stack construída manualmente e Daytona, e sysbox não está em nenhuma delas.
O que você perde é para o que sysbox estava lá. O repositório do serviço sandbox ainda espera que o runner seja executado sob sysbox-runc, e sem ele esse contêiner é equivalente a root no host. Daytona continua sendo a recomendação para produção e é o único caminho que evita tanto a instalação do sysbox quanto o contêiner privilegiado.
Executar o sandbox-runner em uma VM isolada é uma técnica de implantação suportada? Parece valiosa do ponto de vista de segurança, e não quero ter uma dependência de um serviço de terceiros como o Daytona. Ainda seria necessário usar Docker-in-Docker ou pode ser executado diretamente na VM?
Se você usar a configuração de uma linha, tudo está no lugar
Não quero executar a sandbox no mesmo sistema que o n8n, já que tenho outras coisas rodando nesse servidor e um container privilegiado no mesmo sistema assusta
@Daniel Então se você tiver outro sistema, você pode rodar lá e linkar com o primeiro! O mesmo sistema seria mais fácil, mas se você endurecer a segurança da sandbox, você deve ficar bem! Eu mesmo rodo um monte dos meus projetos em um único servidor, claude agents, hermes agents, n8n, searxng, tenho um monte de coisas instaladas e rodando, mas nunca tive nenhum problema!
Acho que tudo bem se você já estiver executando coisas de IA no mesmo servidor, já que provavelmente não há risco adicional ao executar a sandbox do n8n do que o risco que já está presente ao executar o Hermes Agent. No meu caso, é um servidor de produção para um negócio, então executar um contêiner privilegiado é impensável.
Parece que não deveria ser difícil executar sandbox-api e sandbox-runner-1 no Docker em uma VM isolada. Basicamente, eu apenas dividiria o compose.yml em dois.
A documentação é confusa, porém, e parece estar desatualizada. A documentação de configuração do assistente de IA diz para usar N8N_INSTANCE_AI_SANDBOX_API_URL para especificar a URL da sandbox-api, mas não vejo isso sendo usado em lugar nenhum no código. Parece que agora se chama N8N_SANDBOX_SERVICE_URL.
Vou tentar usar uma VM separada quando tiver tempo, usando o código como referência em vez da documentação. Também quero tentar e conseguir que o Docker no Docker funcione sem root (ou seja, tanto o Docker externo quanto o interno sejam executados sem root). Posso tentar atualizar a documentação quando conseguir deixar tudo funcionando, a menos que alguém já esteja planejando atualizá-la.
Esta deve ser a atualização mais recente. Lembre-se, as coisas em Visualização serão fluidas. Espere mudanças em tempo real
Obrigado - esse post de anúncio não existia quando eu estava fazendo minha pesquisa no início da semana. Vou dar uma olhada!