Ich verwende n8n als Self-Hosted-Docker-Image in einem Software-Engineering-Produkt. Wann immer ich von der Entwicklungsumgebung zur SIT wechseln muss: Gibt es eine Möglichkeit, anstatt jedes Mal ein neues Docker-Image auszuführen und alle Workflows von einer Umgebung zur anderen zu kopieren? Die Anzahl der Workflows ist groß
@Mohamed8 kopier sie nicht von hand, nutzen sie den n8n CLI export/import, der verschiebt deine ganze library auf einmal. auf dem dev container exportier alle workflows in einen ordner, kopier den ordner auf die SIT box, dann importier:
# on dev
docker exec -u node <dev-container> n8n export:workflow --backup --output=/tmp/wf/
# copy /tmp/wf across, then on SIT
docker exec -u node <sit-container> n8n import:workflow --separate --input=/tmp/wf/
es gibt auch ein matching export:credentials / import:credentials pair, falls du auch credentials verschieben musst. besser als jedes mal ein frisches image hochzufahren und alles zu kopieren.
Danke. Ich verwende Basic Auth in meinen Workflows, habe sie in den Credentials hinzugefügt und wähle für jede HTTP-Anfrage die passende aus. Wenn ich den Workflow kopiere, werden sie zurückgesetzt und es wird standardmäßig die erste Basic Auth für alle HTTP-Nodes ausgewählt, und ich muss sie reparieren.
Werde ich mit diesem Ansatz auf das gleiche Problem stoßen?
@Mohamed8 der Reset passiert, weil Nodes Credentials nach ID referenzieren und eine einfache Kopie trägt diese IDs nicht mit sich, weshalb es auf die erste passende zurückfällt. Die CLI vermeidet das, solange du die Credentials auch mitnimmst, nicht nur die Workflows: export:credentials --backup auf dev, import:credentials auf SIT. Dieser Import führt ein Upsert nach ID durch, also behält jede Cred ihre ursprüngliche ID und die Workflow-Referenzen lösen sich von selbst zur richtigen Basic Auth auf.
ein Haken: Credentials sind mit N8N_ENCRYPTION_KEY verschlüsselt, also SIT braucht denselben Key wie dev oder sie werden nicht entschlüsselt. Falls die Keys sich unterscheiden, exportiere mit --decrypted und sie werden beim Import neu verschlüsselt.
Großartig! Hast du eine Idee, wie ich auf diesen Verschlüsselungsschlüssel zugreifen kann? Und ob er auch exportiert werden kann oder nicht?
@Mohamed8 es wird nicht mit den Workflows exportiert. Es ist entweder die N8N_ENCRYPTION_KEY Umgebungsvariable, wenn du eine gesetzt hast, oder wenn du das nie getan hast, hat n8n sie automatisch generiert und in der Konfigurationsdatei gespeichert. Lies sie auf dev mit:
docker exec -u node <dev-container> cat /home/node/.n8n/config
du wirst einen encryptionKey-Wert darin sehen. Der einfachste Weg ist, denselben Wert als N8N_ENCRYPTION_KEY auf SIT zu setzen (in deiner compose/run-Umgebung), dann teilen beide den Schlüssel und die importierten Anmeldedaten werden entschlüsselt. Es explizit auf beiden zu setzen ist besser, als sich auf die automatisch generierte Datei zu verlassen.
Hey @Mohamed8, @achamm 's CLI-Ansatz ist die richtige Lösung für das, was du derzeit hast. Eine Sache, die du langfristig bedenken solltest, da dies wie ein wiederkehrender dev→SIT-Promotion in einer echten Product-Pipeline klingt: n8n unterstützt Source Control über Git (Settings → Source Control, verfügbar bei bestimmten Plänen), was dies in einen echten CI/CD-ähnlichen Workflow umwandelt: Push-Workflows von dev in ein Git-Repository, dann automatisches Pull/Deploy zu SIT. Außerdem versioniert es deine Workflows richtig, sodass du kostenlos Diffs und Rollback erhältst, anstatt jedes Mal manuell zu exportieren/importieren.
Wenn Git-basierte Source Control bei deinem Plan/Edition nicht verfügbar ist, ist @achamm 's CLI-Export/Import das richtige manuelle Äquivalent, aber es ist wichtig zu wissen, dass die automatisierte Option existiert, falls dieser Pipeline-Schritt häufiger vorkommt, anstatt eine einmalige Migration zu sein.
Ich habe ein Problem beim Importieren meiner Workflows in meine neue Umgebung.
Ich erhalte einen Fehler
Active version not found for workflow
Error: Active version not found for workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:248:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Could not remove webhooks of workflow "0YdMxcy7MAjVkwy2" because of error: "Active version not found for workflow"
Could not find workflow
Error: Could not find workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:244:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Da meine Workflows Webhook-Trigger haben und einige davon aktiv sind und meine n8n-Version 2.1.4 ist, habt ihr eine Idee?
@ShawnWilliams @achamm
@Mohamed8 das ist der Import, der versucht, den aktiven Status der Workflows zu verwalten. Neuere n8n-Versionen verfolgen aktive Workflows über eine Versions-ID, und das Importieren eines aktiven Workflows, dessen active-version-Datensatz auf SIT noch nicht existiert, führt dazu, dass clearWebhooks fehlschlägt. Die sauberste Lösung ist, sie inaktiv zu importieren: Deaktiviere die Workflows auf dev, bevor du sie exportierst, damit sie mit active:false importiert werden, und aktiviere sie dann auf SIT, nachdem sie geladen sind. Falls der fehlgeschlagene Run halb importierte Kopien aktiv auf SIT hinterlassen hat, deaktiviere oder lösche diese zuerst, damit der nächste Import nicht versucht, Webhooks für sie zu löschen.
Gibt es eine Möglichkeit, sie über die CLI zu aktivieren/deaktivieren?
@Mohamed8 ja, das macht der n8n update:workflow Befehl:
docker exec -u node <container> n8n update:workflow --all --active=false
–active=true umschalten zum Aktivieren, oder --id= statt --all verwenden um nur einen zu bearbeiten. Dein Flow wird dann: auf Dev deaktivieren, exportieren, zu SIT importieren, dann dort mit --active=true ausführen. Falls du nicht möchtest, dass Dev offline geht, einfach die steckengebliebenen Kopien auf SIT mit --all --active=false deaktivieren, neu importieren, dann dort reaktivieren.
Danke dir viel für deine Hilfe. @achamm
wenn ich versuche, es einzeln zu veröffentlichen, bekomme ich einen Fehler
Publishing workflow with ID: Error tracking disabled because this release is older than 6 weeks. (current version)
Error updating database. See log messages for details.
GOT ERROR
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Error: Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
at WorkflowRepository.publishVersion (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/
+db@file+packages+
+db_@opentelemetry+api@1.9.0_@opentelemetry+sdk-trace-base@1._ab22bba05a964211b9fe14bf4b841570/node_modules/
/db/src/repositories/workflow.repository.ts:894:11)
at PublishWorkflowCommand.run (/usr/local/lib/node_modules/n8n/src/commands/publish/workflow.ts:43:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Publishing 0YdMxcy7MAjVkwy2
Error tracking disabled because this release is older than 6 weeks.
Publishing workflow with ID: 0YdMxcy7MAjVkwy2 (current version)
Error updating database. See log messages for details.
auch wenn ich versuche, es über die Benutzeroberfläche zu veröffentlichen, wird mir angezeigt: Workflow konnte nicht veröffentlicht werden:
Version nicht gefunden
@Mohamed8 mach sie nicht einzeln, das per-id publish ist das Engpass, die workflow id wird nicht aufgelöst, deshalb kann n8n sie nicht finden. führ einfach das bulk activate aus:
docker exec -u node <container> n8n update:workflow --all --active=true
es aktiviert sie alle auf einmal, ohne dass du einzelne ids übergeben musst. falls auch --all fehlschlägt, dann ist das wahrscheinlich eine Eigenheit in dem Build, auf dem du bist (die 6-Wochen-Zeile bedeutet, dass es ein älteres Release ist), und ein Upgrade auf eine aktuelle n8n-Version lohnt sich.
Die CLI-Empfehlung zum Export/Import ist die richtige Grundlage. Wenn du viele Workflows hast, würde ich die Promotion von dev → SIT auch eher als Release-Prozess behandeln, nicht als bloße Copy-Operation.
Die Punkte, die ich ergänzen würde:
- Behalte Exporte in der Versionskontrolle, damit du weißt, was sich zwischen den Promotionen geändert hat.
- Trenne die Workflow-Struktur von umgebungsspezifischen Werten.
- Verschiebe nicht einfach so Produktionsanmeldedaten – es sei denn, du hast ein klares Modell für die Verwaltung von Anmeldedaten.
- Führe nach dem Import Smoke-Tests für die Workflows durch, die wichtig sind.
- Dokumentiere, welche Workflows promoted wurden, welche fehlgeschlagen sind und was manuell nachbearbeitet werden muss.
- Halte einen Rollback-Pfad bereit – auch wenn das nur das erneute Importieren eines bekannten guten Exports ist.
Der Copy-Schritt ist normalerweise nicht das Problem, das später Kopfschmerzen bereitet. Der schmerzhafte Teil ist, wenn keiner mehr weiß, welche Version in welcher Umgebung läuft, ob SIT tatsächlich getestet wurde oder welcher Workflow nach dem Umzug kaputt gegangen ist. Dieses Promotion-Protokoll wird besonders wichtig, sobald Workflows für Kunden sichtbar sind.
@achamm aber wenn ich
docker exec -u node n8n update:workflow --all --active=true
verwende, sagt es
⚠️ WARNING: The "update:workflow" command is deprecated.
Workflow publishing via "update:workflow --all" is no longer supported.
Please publish workflows individually using: publish:workflow --id=<workflow-id>
@Mohamed8 ja, --all ist veraltet und das neue publish:workflow ist dort, wo du diesen Versionsfehler vorhin bekommen hast. Überspring also die publish CLI und nutze stattdessen die öffentliche REST API, die hat einen dedizierten Aktivierungs-Endpunkt, der die Versionsverwaltung ganz umgeht:
POST /api/v1/workflows/{id}/activate
Generiere einen API-Schlüssel in Einstellungen > n8n API, liste deine Workflows mit GET /api/v1/workflows auf, um die IDs zu grabben, und loop dann den Aktivierungsaufruf über alle. Das ist deine Bulk-Aktivierung, ohne den kaputten publish-Befehl anzufassen.
@achamm Workflow-IDs aus SQLite abzufragen und dann über sie zu iterieren, könnte eine Alternative sein?
@Mohamed8 ja, die IDs aus sqlite zu lesen funktioniert einwandfrei, die Tabelle heißt workflow_entity, also SELECT id FROM workflow_entity gibt dir die Liste (die GET /api/v1/workflows api macht dasselbe und ist nicht an das db-Schema gebunden, aber beide funktionieren). Halte dich einfach beim Lesen auf, aktiviere nicht durch direktes Schreiben von active=1 in sqlite, das übergeht den Trigger/Webhook, den n8n bei der Aktivierung registriert, was genau der Grund ist, warum Workflows in diesem kaputten active-version-Zustand steckenbleiben. Hole dir die IDs wie du willst, aber führe die eigentliche Aktivierung über den API-Endpoint aus, damit n8n die Trigger richtig verdrahtet.
Danke für deine Hilfe @achamm. Glaubst du, dass das Replizieren des n8n-Volumes von DEV zur Verwendung in SIT die Anmeldedaten-IDs und Knoten richtig beibehalten würde?
Ich sehe, dass alle Details in SQLite gespeichert sind, das sich im n8n-Volume befindet.
@Mohamed8 ja, das Klonen des kompletten Volumes funktioniert und ist das sauberste für das Beibehalten aller Attachments — es ist eine Byte-für-Byte-Kopie derselben sqlite-Datenbank, sodass Credential IDs, Workflow IDs und jede Node-Referenz identisch bleiben, nichts muss neu verlinkt werden. Der Encryption Key wird auch mitgenommen, da er sich in .n8n/config innerhalb dieses Volumes befindet, also werden Creds auf SIT entschlüsselt, setz einfach keine andere N8N_ENCRYPTION_KEY Umgebungsvariable auf SIT oder es wird zu Konflikten führen.
Allerdings zwei Fallstricke: es ist ein vollständiger Überschrieb, er ersetzt alles auf SIT und bringt DEVs umgebungsspezifische Konfiguration mit (URLs, Webhook Base, Dev-vs-Prod Cred Values), also perfekt wenn SIT DEV spiegeln soll, weniger geeignet wenn SIT eigene Einstellungen braucht. und stopp n8n vor dem Kopieren der sqlite-Datei, live kopieren kann sie beschädigen, oder nutze sqlite’s .backup für einen sauberen Snapshot. wenn SIT eigene Konfiguration braucht, ist der selektive Export/Import immer noch der bessere Weg.