Ich stand letzte Woche vor einer Architektur-Entscheidung in meinem n8n-Setup: Wo lege ich globale Konstanten ab? API-URLs, Kundennummern, Schwellwerte – Werte, die in mehreren Workflows gebraucht werden und sich gelegentlich ändern.
Drei Optionen habe ich verglichen.
Erstens: Native Variables. Die saubere Lösung – versioniert, auditierbar, dafür gebaut. Gibt’s aber nur auf Enterprise und größeren Cloud-Plänen. Für Self-hosted Community und Starter: nicht verfügbar.
Zweitens: die »globals«-Community-Node. Speichert Werte als Credentials. Funktioniert sofort, sieht elegant aus.
Mein Problem damit: Credentials sind für Secrets gedacht – verschlüsselt, mit Zugriffsrechten, isoliert. Wer Config dort ablegt, mischt API-Keys und harmlose URLs in derselben Liste. Dazu kein Diff, keine Historie, kein Audit-Trail. Und eine Community-Abhängigkeit, die auf Cloud-Migrationen oder Maintainer-Wechsel anfällig ist.
Drittens: Data Table mit Sub-Workflow. Eine Tabelle mit zwei Spalten – key, value. Ein Sub-Workflow, der einmal liest und alles als JSON zurückgibt. Am Anfang jedes Workflows aufgerufen.
Mein Weg.
Native Nodes, keine Community-Abhängigkeit. Programmatisch les- und schreibbar – ich kann Werte aus Workflows heraus setzen, nicht nur lesen. Inspektion über die UI in zwei Klicks. Klare Trennung: Secrets bleiben in Credentials, Config liegt im Data Table.
Den einen Trade-off nehme ich in Kauf: Jeder Workflow startet mit einem Sub-Workflow-Call. Das ist eine zusätzliche Execution pro Lauf. In meinen Workflows fällt das nicht ins Gewicht – bei sehr hochfrequenten Setups würde ich das nochmal durchrechnen.
Wie löst du das Globals-Problem in n8n? Variables, Community-Node, Data Table – oder einen vierten Weg, den ich übersehe?