Umgebungsvariablen im Airtable-Node auf selbstgehostetem n8n 2.19.5 blockiert – erwartetes Verhalten oder Fehlkonfiguration?

Fragen
1

Hi zusammen,
Ich betreibe selbstgehostetes n8n v2.19.5 auf einem VPS mit Docker Compose. Ich versuche, einen produktionsreifen Lead-Gen-Workflow zu erstellen und bin auf etwas Verwirrendes bezüglich Umgebungsvariablen in Node-Parametern gestoßen.

Problem

Wenn ich versuche, eine Umgebungsvariable im Airtable-Node (Base → By ID) zu referenzieren, wie hier:

Code

{{$env.AIRTABLE_BASE_ID}}

…bekomme ich diese Fehlermeldung direkt in der UI:

Code

[ERROR: access to env vars denied]

Wenn ich die Expression-Klammern entferne und nur Klartext eingebe, verschwindet der Fehler.
Wenn ich die Base ID hardcodiere, gibt es keinen Fehler.
Wenn ich $env.AIRTABLE_BASE_ID in einem Function-Node verwende, funktioniert es einwandfrei.

Es scheint also, dass Umgebungsvariablen zur Laufzeit verfügbar sind, aber in UI-Expressions blockiert werden.

Kontext

  • Selbstgehostetes n8n 2.19.5

  • Docker Compose Deployment

  • Umgebungsvariablen in docker-compose.yml definiert

  • Airtable Personal Access Token Authentifizierung funktioniert

  • “From List” Dropdown wirft 403 (erwartet aufgrund von Airtable-Bereichen)

  • Der einzige Blocker ist Umgebungsvariablen-Zugriff in Node-Parametern

Fragen

  1. Ist dies erwartetes Verhalten für die kostenlose selbstgehostete Version von n8n 2.x?

  2. Werden Umgebungsvariablen absichtlich in UI-Expressions blockiert, es sei denn, es wird n8n Pro verwendet?

  3. Welche ist die empfohlene Lösung für selbstgehostete Nutzer, die wiederverwendbare Workflows möchten (z. B. Base ID in Authentifizierungen speichern)?

  4. Gibt es eine offizielle Dokumentation, die diese Einschränkung erklärt?

Ziel

Ich möchte wiederverwendbare Workflows ohne hardcodierte Base IDs erstellen, möchte aber verstehen, ob diese Einschränkung beabsichtigt ist oder ob ich etwas falsch konfiguriert habe.

Danke im Voraus an alle, die erklären können, wie Umgebungsvariablen in Node-Parametern auf selbstgehosteter 2.x funktionieren sollen

Informationen zu deinem n8n Setup

  • n8n Version: v2.19.5
  • Datenbank (Standard: SQLite):
  • n8n EXECUTIONS_PROCESS Einstellung (Standard: own, main):
  • n8n ausgeführt über (Docker, npm, n8n cloud, Desktop-App): Docker Compose
  • Betriebssystem: Ubuntu
3

Ja

Nein

Dies

4

Danke für die Links! Ich habe die Dokumentation gelesen und mir auch das Issue angesehen. Es sieht so aus, als würde die Änderung hauptsächlich den Zugriff auf Umgebungsvariablen in Code-Knoten beeinflussen, und das kann mit N8N_BLOCK_ENV_ACCESS_IN_NODE umgeschaltet werden. In meinem Fall funktioniert $env in Code-Knoten einwandfrei – das Blockieren ist nicht das Problem. Das Problem ist, dass Umgebungsvariablen speziell in Knotenparameter-Ausdrücken (z. B. Airtable Base ID) verweigert werden, wobei ich [ERROR: access to env vars denied] erhalte, obwohl die Variable im Container vorhanden ist. Soweit ich das beurteilen kann, scheint dies eine separate Einschränkung im 2.x UI-Ausdruckssystem zu sein. Ich versuche nur zu bestätigen, ob dies das erwartete Verhalten für die kostenlose selbstgehostete Version ist.

5

Guten Morgen @NE_automation
Das ist ein Sicherheitsverhalten von n8n 2.x
Verwenden Sie N8N_BLOCK_ENV_ACCESS_IN_NODE=false und starten Sie Ihren Container neu

6

Danke für den Vorschlag! Ich habe bereits N8N_BLOCK_ENV_ACCESS_IN_NODE=false getestet und $env funktioniert in Code-Knoten einwandfrei. Das Problem, auf das ich stoße, ist jedoch anders – Umgebungsvariablen werden speziell in Knotenparameter-Ausdrücken blockiert (wie in den Airtable-Feldern „Table

7

Danke an alle für die Hilfe! Ich habe es herausgefunden - das Problem war, dass ich +bases unter Access hinzugefügt habe, aber vergessen habe, schema.bases:read unter Scopes zu aktivieren. Nachdem ich diesen Scope hinzugefügt habe, funktionierte alles. Ich schätze es, dass alle eingegriffen haben.

8

Markieren Sie Ihre Antwort als Lösung, damit andere Mitglieder ihre Fragen leichter lösen können. Cheers :tada: