Wir haben eine einzelne n8n-Instanz für Dev und Prod – wie können wir die Secrets separat verwalten und wie können wir diese in Workflows verwenden?
Hallo @mylearnings_abu
Eine einzelne Instanz, die von dev und prod gemeinsam genutzt wird, kann Secrets nicht wirklich trennen, da es darin nur einen Secret-Kontext gibt. Das beabsichtigte Muster von n8n ist zwei Instanzen, eine für dev und eine für prod, mit Workflows, die durch Source Control synchronisiert werden.
Für die Secrets ist die Funktion, die du möchtest, External Secrets (Enterprise). Du verbindest einen Vault wie AWS Secrets Manager, Azure Key Vault oder HashiCorp Vault und verweist dann deine dev-Instanz auf den dev-Vault und prod auf den prod-Vault. In einem Credential-Feld referenzierst du einen Wert als $secrets.yourVaultName.secretName, sodass das Secret nie im Workflow selbst gespeichert ist.
Wenn du auf einer Instanz bleiben musst, ist der realistische Workaround separate dev- und prod-Credentials, aber das ist keine echte Isolation.
Hallo @mylearnings_abu
Ich stimme @achamm zu, dass der „saubere
@mylearnings_abu hallo
Wenn du einen Enterprise Cloud Plan hast, kannst du separate Vaults für jede Umgebung mit der External Secrets Funktionalität verbinden; für Self-Hosted kannst du Credential Overwrites über Umgebungsvariablen oder REST Endpoint nutzen; aber falls du die Cloud Community Edition nutzt, ist eine praktische Lösung, separate Anmeldedaten für Dev und Prod zu erstellen, die URLs/Configs in einer Datenbank oder Google Sheets zu speichern und jeden Workflow so zu starten, dass er die richtige Konfiguration basierend auf einer Umgebungsvariable ENV=dev oder ENV=prod abruft
Hallo @mylearnings_abu
Both environments auf einer Instanz zu betreiben ist riskant, da ein Fehler in einem Test-Workflow dein gesamtes System zum Absturz bringen könnte. Wenn dein Unternehmen stark auf diese Automatisierungen angewiesen ist, ist der sicherste langfristige Weg, zwei völlig separate n8n-Installationen einzurichten – eine zum Experimentieren und eine für die Live-Produktion.
Um deine Frage zu beantworten: Wir verwenden ein selbst gehostetes Setup mit Enterprise Plan und betreiben derzeit nur eine Instanz
Da du Self-Hosted Enterprise verwendest, aber immer noch auf einer Instanz läufst, helfen separate Vault-Werte zwar bei der Credential-Hygiene, aber sie ermöglichen keine echte Isolation zwischen Dev und Prod. Ein Test-Workflow kann immer noch im selben Execution/Runtime-Pfad wie Production ausgeführt werden.
Die saubere Aufteilung ist immer noch zwei n8n-Instanzen, die sich Source-Control-Workflows teilen, wobei jede auf ihren eigenen Vault/ihre eigene Env verweist. Falls du noch nicht aufteilen kannst, halte die Kurzfrist-Regel einfach: Prod-Credentials nur auf Prod-Workflows, Dev-Credentials auf kopierten Dev-Workflows, und keine gemeinsamen Credential-Namen zwischen ihnen. Ist der Blocker nur die Credential-Separation, oder musst du auch verhindern, dass Dev-Runs/Webhooks Production-Systeme berühren?
Da du Self-Hosted Enterprise auf einer einzigen Instanz betreibst, ist Credential Overwrites das saubere Muster dafür. Injiziere Secrets auf Umgebungsebene über CREDENTIALS_OVERWRITE_DATA in deiner Docker-Konfiguration, damit sie nie in der Benutzeroberfläche oder Datenbank erscheinen:
environment:
- CREDENTIALS_OVERWRITE_DATA={“ProdDB”:{“host”:“prod-db.internal”,“password”:“prod-secret”},“DevDB”:{“host”:“dev-db.internal”,“password”:“dev-secret”}}
Workflow-Builder erstellen Anmeldedaten mit den Namen ProdDB / DevDB in der Benutzeroberfläche mit leeren sensitiven Feldern, und n8n injiziert die echten Werte zur Laufzeit stillschweigend.
Kombiniere das mit zwei Vault-Pfaden in deinem External-Secrets-Backend (/n8n/dev/ und /n8n/prod/) und referenziere sie explizit in Workflows als $secrets.dev.API_KEY vs $secrets.prod.API_KEY.
Das Runtime-Isolationsrisiko, das @oimrqs_ops erwähnt hat, ist auf einer einzelnen Instanz immer noch real – minimiere es, indem du Dev-Workflows deaktiviert lässt, wenn du nicht aktiv Tests durchführst.