💬 Sua opinião sobre uma mudança proposta: exigir Docker para executar n8n

Anúncios
1

Até agora, sempre houve duas principais formas de fazer deploy do n8n: via npm e via Docker. Estamos considerando descontinuar o suporte nativo para npm e gostaríamos de receber seu feedback sobre isso.

Nós adoraríamos se você pudesse preencher esta pesquisa após a leitura.

Por que estamos considerando isso

Estamos trabalhando muito em um assistente de IA muito mais poderoso - pense em Claude Code, mas integrado ao n8n. Isso está no topo da lista de desejos da comunidade há muito tempo, e é importante que tragamos isso para auto-hospedagem. Estamos visando um lançamento auto-hospedado neste verão.

Por questões de segurança, este assistente precisa de um sandbox. Esse sandbox precisa ser implantado em um contêiner Docker separado. Isso significa que o n8n terá uma dependência do Docker. Por causa disso, faz sentido padronizar em um deployment baseado em Docker - particularmente porque é um método de deployment mais confiável de qualquer forma.

O que isso significaria para instalações baseadas em npm

Se você quisesse fazer upgrade, precisaria garantir que o Docker estivesse instalado e fazer deploy usando esse método em vez disso. Você ainda poderia manter sua instalação no mesmo diretório e montar esse diretório no Docker. Forneceremos orientações sobre como fazer isso.

Se eu não quiser o assistente, por que não posso continuar rodando o resto do n8n via npm?

Embora isso seja tecnicamente possível, quanto mais diferentes variações e configurações um produto tiver, mais complexidade e bugs se introduzem.

Existem outros benefícios ao migrar para apenas Docker; o assistente é apenas o mais imediato. Fazer isso:

  • Aceleraria o desenvolvimento do n8n
  • Tornaria o n8n mais fácil de suportar
  • Abriria a porta para agrupar outros produtos com o n8n no futuro, se necessário, por exemplo um banco de dados vetorial ou Redis.

O que gostaríamos de saber

Estamos cientes de que pode haver algumas situações em que usar Docker é difícil. n8n é usado de todas as formas possíveis e algumas delas provavelmente nem mesmo sabemos. Então gostaríamos de ouvir de todos sobre este tópico, quer você use npm ou Docker atualmente — por favor, preencha a pesquisa abaixo! :folded_hands:

:backhand_index_pointing_right: Link para pesquisa

11 curtidas
3

Apoio isso. Faz muito tempo que não uso uma instalação de npm do n8n, a não ser ao desenvolver nodes.
Usar npm para instalações do n8n sempre leva a problemas em algum momento. Docker também é mais seguro.
Quando clientes querem que gerenciemos sua instância, sempre os incentivamos a usar Docker se estiverem usando npm. Facilita muito o gerenciamento. :slight_smile:

12 curtidas
4

Concordo com o Bram, docker é muito mais fácil de configurar e é mais rápido e tem containers para ajudar a manter as coisas seguras.

5 curtidas
5

Apoio essa direção. Eu mesmo rodo n8n em Docker e experimentei brevemente com npm antes. A diferença em estabilidade e manutenibilidade é clara.
O que me convence na decisão: O assistente de IA integrado precisa de uma sandbox, e uma sandbox precisa de Docker. Essa não é uma dependência arbitrária, mas justificada tecnicamente. Quem usa n8n seriamente geralmente já tem Docker rodando mesmo assim.
O único ponto que me deixa pensativo: Existem usuários que rodam n8n em ambientes muito enxutos, por exemplo pequenos VPS sem muita RAM, onde Docker custa notavelmente mais recursos do que uma instalação pura com npm. Para eles seria importante uma ajuda de migração clara e, idealmente, uma imagem Docker otimizada.
No geral: Menos variantes significa menos bugs e desenvolvimento mais rápido. Isso beneficia toda a comunidade.

3 curtidas
6

Bem, é hora de entrar na toca do coelho do Docker com tutoriais de CLI e Desktop.
Se algum mago conseguir compartilhar um Dockerfile completo com fila, workers, task runners, postgresql, redis… com certeza conseguimos impedir que os amantes de npm façam isso novamente no futuro :slight_smile:

P.S alguns amam npm… alguns amam docker… mas o mais importante é que TODOS amam N8N!!!

1 curtida
7

Concordo: Docker parece ser o caminho mais limpo e mais fácil de manter aqui, especialmente para a sandbox do assistente de IA e a estabilidade a longo prazo.

1 curtida
8

Atualizar do npm foi um pesadelo. Havia muitos problemas de dependência.
Docker é mais fácil, embora tenha alguns overheads. Gerenciabilidade é a chave.

+1 para Docker

1 curtida
9

Apoio essa direção. Por ter executado n8n em instâncias VPS para múltiplos ambientes de clientes, Docker tem sido significativamente mais previsível que npm entre versões do n8n - especialmente quando a sandbox de IA começou a exigir isolamento de processo separado.

O único pedido concreto que eu adicionaria: um arquivo Compose minimalista de um único container otimizado para VPS pequenas (1-2 vCPU, 1-2 GB RAM) com documentação clara sobre quais serviços podem ser desabilitados para reduzir overhead. Muitos usuários self-hosted executam n8n em VPS orçamentárias onde o daemon Docker em si adiciona pressão de memória, então orientação sobre a configuração mínima viável do Docker reduziria o atrito para essas migrações.

4 curtidas
10

Estou executando Docker em um VPS Ubuntu via MobaXterm. Este método é um pouco técnico, mas qualquer pessoa que já o tenha usado provavelmente o preferirá a longo prazo.
Docker Compose + Cloudflare Tunnel é uma configuração essencial para usuários - bastante fácil de fazer backup, manter e até migrar dados.
O requisito de um ambiente sandbox para o assistente de IA é apenas um benefício adicional.

No entanto, a configuração atual do Docker Compose precisa de alguma alteração quando o assistente é iniciado? Ou é apenas um contêiner adicional que se conecta e é executado no mesmo sistema?

11

Deveria ser apenas um contêiner extra, sim :+1:

2 curtidas
12

Obrigado pela transparência nisso. Concordo que há benefícios em migrar para Docker, mas também alguns desafios técnicos, incluindo acesso a arquivos locais e permissão para operações de linha de comando como criar pastas e arquivos. Isso funciona com múltiplos ajustes atualmente e ficará ainda mais complexo com a adição do Docker na mistura.

Outra parte que pode complicar as coisas é a própria licença do Docker e o que isso significa para alguns usuários.

13

Muito boa ideia, além disso, o nome do roubo por npm cresceu, então pode prejudicar os dados de alguém ao trabalhar em n8n. E para instalar n8n em docker é necessário ter conhecimentos técnicos, mas é possível aprender, eu mesmo tive problemas ao instalar n8n em docker desktop, mas resolvi passo a passo procurando no youtube e perguntando para o AI chinês Deepseek.

14

apoiado, questionário respondido

2 curtidas
15

Felizmente, o Coolify torna o Docker mais amigável. O acesso a arquivos continua sendo algo não fácil de lidar.

1 curtida
16

Executar n8n auto-hospedado para uma plataforma SaaS com múltiplos locatários - suporte total ao Docker-first. Tudo sobre a configuração multi-worker e modo fila funciona de forma mais confiável quando a versão do n8n e o ambiente de tempo de execução são consistentes entre os containers principal, workers e webhooks. Instalações baseadas em npm divergem no nível do sistema operacional do host e causam diferenças sutis entre ambientes que são difíceis de debugar. O requisito de sandboxing do assistente de IA é apenas o ponto final natural de uma direção que já era a escolha correta para implantações em produção.

17

Que notícia decepcionante - não sou (ainda :wink: um especialista, mas tentei usar Docker e ele deixou minha máquina travada (Windows com 16GB de RAM e n8n instalado localmente). Quando desinstalei Docker e voltei a usar NPM, consegui trabalhar de verdade no n8n em vez de ficar gastando tempo resolvendo problemas de recursos. Sim, eu poderia atualizar minha máquina, mas alguns dos meus clientes têm configurações mais básicas e às vezes preciso trabalhar com o que eles têm.
Da minha perspectiva (ainda que limitada), usar Docker parece adicionar uma camada desnecessária de complexidade e sobrecarga para situações simples. Se Docker precisa ser usado por razões técnicas, será que precisa ser tão ganancioso?

2 curtidas
18

Na minha opinião, até mesmo não-administradores conseguem instalar Docker, e graças a ferramentas como Portainer, também é fácil gerenciar. Isso facilita para iniciantes (como eu) que não querem uma solução em nuvem começar.

Ter múltiplas opções frequentemente deixa muitas pessoas enfrentando um dilema na hora de tomar uma decisão. Às vezes é bom ter a decisão tomada para você (estou me referindo aqui a usuários que só querem testar uma instalação).

Estou animado com a ideia de um assistente de IA, e tenho certeza de que ajudará a n8n fazer grandes avanços.

Pesquisa finalizada? Pronto :wink:

2 curtidas
19

Estou de acordo com a direção Docker-only para a maioria dos usuários, e uma imagem padrão enxuta, endurecida e sem permissões de root faz sentido. Mas ela tem duas propriedades que tornam difícil executá-la bem em hosts NAS/self-hosted (Unraid, Synology, …), e passar para Docker-only transforma essas de “apenas use npm” em bloqueadores críticos:

  1. Sem mapeamento de UID/GID do host. A imagem é executada como um usuário node fixo (uid 1000), então os compartilhamentos bind-mounted acabam sendo propriedade do UID/GID errado no host. A solução estabelecida (imagens LinuxServer.io e similares) é iniciar como root, fazer a configuração de primeira execução e depois reduzir para um usuário remapeado a partir de PUID/PGID fornecidos pelo host - assim o container nunca danifica as permissões de compartilhamento.

  2. Sem gerenciador de pacotes (apk foi removido). Algumas integrações NAS precisam de root + um gerenciador de pacotes na primeira execução - por exemplo, a integração Tailscale do Unraid usa um hook que instala e configura o Tailscale no início do container, impossível uma vez que apk/apt é removido.

Importantemente, (1) não pode ser apenas uma flag de env na imagem atual: o remapeamento de UID (chown de dados montados, usermod, redução via su-exec/gosu) fundamentalmente requer que o container inicie como root. Essa é uma mudança deliberada de postura em relação ao padrão não-root endurecido - que é exatamente por que acho que isso deveria estar em uma imagem separada em vez de enfraquecer o padrão.

Então: a equipe consideraria manter oficialmente uma variante self-hosted/NAS - por exemplo, n8nio/n8n:<version>-nas - que inicia como root, remapeia para PUID/PGID do host, reduz privilégios e mantém um gerenciador de pacotes disponível para hooks de primeira execução? O padrão endurecido permanece exatamente como está para todos os outros.

1 curtida
20

Não, obrigado. Migrei do Docker para bare metal. Muitos comandos extras “docker says” só para implementar o que preciso fazer. “Mas Docker é muito mais seguro!” Como se hackers não soubessem comandos do Docker e como contornar as coisas… passo…