Temos uma única instância de n8n para dev e prod. Como podemos gerenciar os segredos separadamente e como usá-los no workflow?
Uma única instância compartilhada por dev e prod não consegue realmente separar secrets, já que há apenas um contexto de secrets nela. O padrão pretendido pelo n8n é duas instâncias, uma para dev e outra para prod, com seus workflows sincronizados através do Source Control.
Para os secrets, o recurso que você quer é External Secrets (Enterprise). Você conecta um vault como AWS Secrets Manager, Azure Key Vault ou HashiCorp Vault, depois aponta sua instância dev para o vault dev e a prod para o vault prod. Em um campo de credencial você referencia um valor como $secrets.yourVaultName.secretName, assim o secret nunca fica no workflow em si.
Se você precisa ficar em uma única instância, o workaround realista é usar credenciais dev e prod separadas, mas isso não é um isolamento real.
Concordo com @achamm que a forma “correta” é ter instâncias separadas de dev/prod – é a única maneira de conseguir isolamento real para secrets e execuções.
Se você está preso a uma única instância por enquanto mas está em um plano que suporta External Secrets, há uma coisa extra que você pode fazer para pelo menos separar valores logicamente:
-
Crie dois vaults no seu backend de secrets, por exemplo
deveprod -
Conecte ambos no n8n em Settings → External Secrets
-
Depois referencie-os explicitamente nas suas credentials/expressions, por exemplo:
-
{{ $secrets.dev.MY_API_KEY }}para dev -
{{ $secrets.prod.MY_API_KEY }}para prod
-
Isso não te dá isolamento rígido como duas instâncias, mas evita ter uma única credential “misturada” e deixa bem claro qual ambiente um workflow está acessando.
Se você compartilhar um pouco mais sobre sua configuração (Cloud vs self‑hosted, e qual plano), as pessoas aqui provavelmente podem sugerir um padrão concreto que se adeque às suas limitações.
@mylearnings_abu olá
Se você tiver um plano cloud Enterprise, pode conectar vaults separados para cada ambiente usando a funcionalidade de External Secrets; para self hosted você pode usar Credential Overwrites via variável de ambiente ou endpoint REST; mas se estiver no cloud community edition uma solução prática é Criar credenciais separadas para dev e prod, Armazenar as URLs/configs em um banco de dados ou Google Sheets e iniciar cada workflow buscando a configuração correta com base em uma variável de ambiente ENV=dev ou ENV=prod
Executar ambos os ambientes em uma única instância é arriscado porque um erro em um fluxo de trabalho de teste poderia derrubar todo o seu sistema. Se seu negócio depende muito dessas automações, o movimento mais seguro a longo prazo é configurar duas instalações n8n completamente separadas—uma para experimentação e outra para produção ao vivo.
Para responder sua pergunta, estamos usando uma configuração auto hospedada com o Plano Enterprise e atualmente temos apenas uma instância em execução
Como você está em uma implementação Self-hosted Enterprise, mas ainda em uma única instância, valores de vault separados ajudam com a higiene de credenciais, mas não tornam dev e prod verdadeiramente isolados. Um workflow de teste ainda pode ser executado no mesmo caminho de execução/runtime que a produção.
A divisão limpa ainda é duas instâncias n8n compartilhando workflows controlados por versionamento, cada uma apontando para seu próprio vault/env. Se você ainda não consegue fazer a divisão, mantenha a regra de curto prazo simples: credenciais de prod apenas em workflows de prod, credenciais de dev em workflows de dev copiados, e sem nomes de credenciais compartilhados entre eles. O bloqueio é apenas a separação de credenciais, ou você também precisa impedir que execuções/webhooks de dev toquem em sistemas de produção?
Como você está com o Enterprise auto-hospedado em uma instância, Credential Overwrites é o padrão mais limpo para isso, injete secrets no nível de ambiente via CREDENTIALS_OVERWRITE_DATA na sua configuração Docker para que nunca apareçam na UI ou banco de dados:
environment:
- CREDENTIALS_OVERWRITE_DATA={“ProdDB”:{“host”:“prod-db.internal”,“password”:“prod-secret”},“DevDB”:{“host”:“dev-db.internal”,“password”:“dev-secret”}}
Construtores de Workflow criam credenciais nomeadas ProdDB / DevDB na UI com os campos sensíveis em branco, n8n injeta os valores reais em tempo de execução silenciosamente.
Combine isso com dois caminhos de vault no seu backend External Secrets (/n8n/dev/ e /n8n/prod/), e os referencie explicitamente em workflows como $secrets.dev.API_KEY vs $secrets.prod.API_KEY.
O risco de isolamento em tempo de execução que @oimrqs_ops mencionou ainda é real em uma instância, mitigue-o mantendo workflows de dev desabilitados quando não estiver testando ativamente.