¿Cómo gestionar secretos a nivel de entorno en n8n?

Preguntas
1

¿Cómo podemos gestionar los secretos por separado si tenemos una única instancia de n8n para dev y prod y cómo podemos usarlos en el flujo de trabajo?

2

Hola @mylearnings_abu

Una instancia única compartida por dev y prod no puede realmente separar secretos, ya que solo hay un contexto de secretos en ella. El patrón previsto de n8n es dos instancias, una para dev y otra para prod, con sus flujos de trabajo sincronizados a través de Control de Código Fuente.

Para los secretos, la funcionalidad que necesitas es External Secrets (Enterprise). Conectas un almacén como AWS Secrets Manager, Azure Key Vault o HashiCorp Vault, luego apuntas tu instancia de dev al almacén de dev y la de prod al de prod. En un campo de credencial referencias un valor como $secrets.yourVaultName.secretName, por lo que el secreto nunca existe en el flujo de trabajo en sí.

Si debes quedarte con una sola instancia, el workaround realista es usar credenciales separadas de dev y prod, pero eso no es un verdadero aislamiento.

3

Hola @mylearnings_abu

Estoy de acuerdo con @achamm en que la forma «limpia» es tener instancias separadas de desarrollo y producción – es la única forma de lograr un aislamiento real para secretos y ejecuciones.

Si por ahora estás limitado a una sola instancia pero tu plan admite External Secrets, hay una cosa extra que puedes hacer para al menos separar los valores lógicamente:

  • Crea dos bóvedas en tu backend de secretos, por ejemplo dev y prod

  • Conecta ambas en n8n en Configuración → External Secrets

  • Luego haz referencia a ellas explícitamente en tus credenciales / expresiones, por ejemplo:

    • {{ $secrets.dev.MY_API_KEY }} para desarrollo

    • {{ $secrets.prod.MY_API_KEY }} para producción

Esto no te da el aislamiento total como dos instancias, pero evita tener una credencial única «mixta» y deja muy claro en qué entorno un flujo de trabajo se está comunicando.

Si compartes un poco más sobre tu configuración (Cloud vs auto-hospedado, y qué plan tienes), la gente aquí probablemente pueda sugerirte un patrón concreto que se ajuste a tus limitaciones.

4

@mylearnings_abu hola

Si tienes un plan cloud Enterprise, puedes conectar vaults separados para cada entorno usando la funcionalidad de External Secrets; para self hosted puedes usar Credential Overwrites mediante variable de entorno o endpoint REST; pero si estás en cloud community edition una solución práctica es Crear credenciales separadas para dev y prod, Almacenar las URLs/configs en una base de datos o Google Sheets e iniciar cada workflow buscando la configuración correcta basándote en una variable de entorno ENV=dev o ENV=prod

5

Hola @mylearnings_abu

Ejectutar ambos entornos en una sola instancia es riesgoso porque un error en un flujo de prueba podría bloquear tu sistema completo. Si tu negocio depende mucho de estas automatizaciones, el movimiento más seguro a largo plazo es configurar dos instalaciones de n8n completamente separadas—una para experimentos y otra para producción en vivo.

6

Para responder a tu pregunta, estamos utilizando una configuración auto-hospedada con Plan Enterprise y actualmente tenemos solo una instancia en ejecución

7

Como eres auto-hospedado Enterprise pero aún en una sola instancia, valores de bóveda separados ayudan con la higiene de credenciales, pero no hacen que dev y prod estén verdaderamente aislados. Un flujo de trabajo de prueba puede ejecutarse en la misma ruta de ejecución/tiempo de ejecución que producción.

La división limpia sigue siendo dos instancias de n8n compartiendo flujos de trabajo controlados por versión, cada una apuntando a su propia bóveda/env. Si aún no puedes dividir, mantén la regla a corto plazo simple: credenciales de prod solo en flujos de trabajo de prod, credenciales de dev en flujos de trabajo de dev copiados, y sin nombres de credenciales compartidas entre ellos. ¿El bloqueador es solo la separación de credenciales, o también necesitas evitar que las ejecuciones/webhooks de dev toquen sistemas de producción?

8

Dado que tienes Enterprise autohospedado en una única instancia, Credential Overwrites es el patrón más limpio para esto. Inyecta secretos a nivel de entorno mediante CREDENTIALS_OVERWRITE_DATA en tu configuración de Docker para que nunca aparezcan en la UI o base de datos:

environment:

  • CREDENTIALS_OVERWRITE_DATA={“ProdDB”:{“host”:“prod-db.internal”,“password”:“prod-secret”},“DevDB”:{“host”:“dev-db.internal”,“password”:“dev-secret”}}

Los constructores de flujos crean credenciales llamadas ProdDB / DevDB en la UI con los campos sensibles en blanco, y n8n inyecta los valores reales en tiempo de ejecución de forma silenciosa.

Combina esto con dos rutas de vault en tu backend de External Secrets (/n8n/dev/ y /n8n/prod/), y referencialas explícitamente en los flujos como $secrets.dev.API_KEY frente a $secrets.prod.API_KEY.

El riesgo de aislamiento en tiempo de ejecución que mencionó @oimrqs_ops sigue siendo real en una única instancia. Mitígalo manteniendo los flujos de desarrollo deshabilitados cuando no estés probando activamente.