n8n 2.0 steht vor der Tür - Jetzt das eigene System vorbereiten!

Die Spatzen pfeifen es bereits von den Dächern der Automatisierungs-Community: n8n 2.0 steht vor der Tür! Kürzlich wurde im offiziellen Forum die neue Version angekündigt, und wie bei jedem Major-Release bringt auch dieses Update einige spannende Neuerungen, aber auch Breaking Changes mit sich.

Die Beta soll bereits am 8. Dezember zur Verfügung stehen. Grund genug, sich jetzt schon mit den Änderungen vertraut zu machen und die eigene Infrastruktur vorzubereiten.

Vorbereitung ist alles: Der Migration Report

Ein Major-Update kann furchteinflößend sein, besonders wenn komplexe Workflows davon abhängen. Das Team von n8n hat hier jedoch mitgedacht. Es gibt einen integrierten Migration Report direkt im Backend deiner n8n-Instanz unter Settings -> Migration Report.

Dieser Report ist dein bester Freund für das Update. Er prüft deine vorhandenen Workflows und Einstellungen auf Herz und Nieren:

• Welche Nodes sind inkompatibel?
• Welche Nodes sind von Änderungen betroffen?
• Welche Konfigurationen müssen angepasst werden?

Ich empfehle jedem, diesen Report so früh wie möglich zu konsultieren, um böse Überraschungen beim Update zu vermeiden. Eine detaillierte Übersicht der Änderungen findest du auch in der offiziellen Dokumentation zu den Breaking Changes.

Wichtige Breaking Changes im Überblick

Neben den architektonischen Änderungen gibt es einige harte Schnitte, die vor allem Self-Hoster betreffen. Hier sind die wichtigsten Punkte aus der Dokumentation:

• Kein MySQL/MariaDB Support mehr: n8n 2.0 stellt die Unterstützung für MySQL und MariaDB als Backend-Datenbank ein. Wenn du diese noch nutzt, ist jetzt der Zeitpunkt, auf PostgreSQL zu migrieren. Der MySQL Support war aber auch schon beim 1.0 Release als deprecated markiert worden. Ich persönlich mag Postgres auch viel lieber.
• Zugriff auf Environment Variables: Aus Sicherheitsgründen können Code Nodes standardmäßig nicht mehr auf Umgebungsvariablen zugreifen. Falls deine Skripte darauf angewiesen sind, musst du dies entweder explizit über die Variable N8N_BLOCK_ENV_ACCESS_IN_NODE=false erlauben oder deine Workflows anpassen.
• Wegfall der Tunnel-Option: Die Start-Option --tunnel, die oft für schnelle lokale Tests mit Webhooks genutzt wurde, ist ersatzlos gestrichen.
• Bereinigung alter Nodes: Nodes für Dienste, die bereits eingestellt wurden oder veraltet sind, wurden nun endgültig aus dem Core entfernt.

Eine große Änderung für mein Setup: Externe Task Runners

Eine der signifikantesten architektonischen Änderungen in n8n 2.0 betrifft die Ausführung von Code. Der interne Task Runner, der bisher "out-of-the-box" Python oder JavaScript Code ausgeführt hat, wird in Version 2.0 nicht mehr standardmäßig aktiv sein.

Stattdessen setzt n8n nun auf externe Task Runners. Das bedeutet, dass Code in einer Sandbox ausgeführt wird, die strikt von der n8n-Hauptinstanz getrennt ist. Das hat zwei große Vorteile:

1. Sicherheit: Die Angriffsfläche für Hacks wird drastisch minimiert. Standardmäßig sind Nodes für "Git" oder Code-Execution eingeschränkt, sodass beispielsweise kein unkontrollierter Zugriff auf das Dateisystem mehr möglich ist. Natürlich lässt sich das über Einstellungen wieder lockern, wenn man genau weiß, was man tut.
2. Flexibilität: Benötigst du spezielle Python-Bibliotheken oder Node-Pakete? Du kannst dir einfach dein eigenes Docker-Image für den Task Runner erstellen und hast genau die Umgebung, die du brauchst, ohne die Hauptinstanz aufzublähen.

Mein Setup: Task Runners im Worker Mode

Da ich mein n8n-Setup im Worker Mode betreibe, um die Last besser zu verteilen, musste ich meine docker-compose.yaml etwas stärker anpassen. Die Herausforderung hierbei ist, dass nicht nur der Haupt-Container (Webhook-Prozessor), sondern auch die Worker Zugriff auf Task Runner benötigen.

In meiner aktuellen Konfiguration, mit der ich mich auf die Umstellung vorbereite, habe ich deshalb dedizierte Task Runner Container für den Hauptprozess (n8n) und für den Worker (n8n_worker) definiert.

Hier ist ein Einblick in meine docker-compose.yaml, wie sie aktuell läuft:

x-n8n-task-runners: &service-task-runners-n8n  
  image: ghcr.io/n8n-io/runners:1.122.1

x-n8n: &service-n8n  
  image: ghcr.io/n8n-io/n8n:1.122.1  
  env_file: .env  
  networks:  
    - default  
  user: node  
  volumes:  
    - n8n-data:/home/node/.n8n  
    - "./data:/data"  
  restart: unless-stopped

services:  
  n8n:  
    <<: *service-n8n  
    container_name: n8n  
    ports:  
      - 0.0.0.0:5678:5678  
    depends_on:  
      redis:  
        condition: service_healthy  
    env_file: .env

  n8n_worker:  
    <<: *service-n8n  
    container_name: n8n_worker  
    command: worker --concurrency=6  
    depends_on:  
      - n8n  
    env_file: .env  
    environment:  
      N8N_WORKER_MODE: "true"  
      OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS: "true"

  n8n_main_task_runners:  
    <<: *service-task-runners-n8n  
    container_name: n8n_task_runners  
    env_file: .env  
    restart: unless-stopped  
    environment:  
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n:5679  
      - N8N_RUNNERS_MAX_CONCURRENCY=5  
      - N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT=15  
      - N8N_NATIVE_PYTHON_RUNNER="true"  
    depends_on:  
      - n8n

  n8n_worker_task_runners:  
    <<: *service-task-runners-n8n  
    container_name: n8n_worker_task_runners  
    env_file: .env  
    restart: unless-stopped  
    environment:  
      - N8N_RUNNERS_TASK_BROKER_URI=http://n8n_worker:5679  
      - N8N_RUNNERS_MAX_CONCURRENCY=5  
      - N8N_RUNNERS_AUTO_SHUTDOWN_TIMEOUT=15  
      - N8N_NATIVE_PYTHON_RUNNER="true"  
    depends_on:  
      - n8n_worker

  redis:  
    container_name: n8n_redis  
    image: redis:8-alpine@sha256:5013e94192ef18a5d8368179c7522e5300f9265cc339cadac76c7b93303a2752  
    restart: unless-stopped  
    networks:  
      - default  
    volumes:  
      - redis-data:/data  
    healthcheck:  
      test: ['CMD', 'redis-cli', 'ping']  
      interval: 5s  
      timeout: 5s  
      retries: 10

volumes:  
  n8n-data:  
  redis-data:

In meiner .env Datei habe ich erstmal folgende Variablen zusätzlich eingetragen:

# Task Runners
N8N_RUNNERS_AUTH_TOKEN=<xxxxxxxxxx>
N8N_RUNNERS_ENABLED=true
N8N_RUNNERS_MODE=external
N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0

# Auth
N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false

# Git
N8N_GIT_NODE_DISABLE_BARE_REPOS=false

N8N_RESTRICT_FILE_ACCESS_TO=/data

# Allow all excluded nodes
NODES_EXCLUDE="[]"

Die Einstellungen sind jetzt erstmal so gewählt, dass meine Workflows weiterlaufen können nach dem Update. Ich habe eine paar wenige Nodes die direkte Bash-Befehle ausführen. Diese arbeiten aber bei mir sowieso nur im Container im Verzeichnis /data.

Wie ihr seht, habe ich n8n_main_task_runners und n8n_worker_task_runners definiert, die jeweils via N8N_RUNNERS_TASK_BROKER_URI mit ihrem entsprechenden n8n-Service verbunden sind. Ob dies die absolut optimale Lösung für jedes Szenario ist, wird sich in der Praxis zeigen, aber es ist ein funktionierender Weg, um die neue Architektur im Worker-Mode abzubilden.

Neue Features: Mehr Komfort für Workflow-Builder

Neben den technischen Änderungen unter der Haube gibt es auch sichtbare Verbesserungen, die das Arbeiten mit n8n angenehmer machen:

• Verbesserte Canvas: Der Workflow-Editor (Canvas) erhält einen frischen Look and Feel, der moderner und aufgeräumter wirkt (Leider habe ich bisher keinen Screenshot gesehen).
• Neue Sidebar: Die Seitenleiste wurde überarbeitet, um die Navigation und den Zugriff auf wichtige Funktionen zu verbessern. Ich bin gespannt ob die Sidebar auch in der Community-Version eine Funktion bekommt,
• Autosave (Bald verfügbar): Endlich! Eines der am meisten gewünschten Features kommt. Das automatische Speichern von Workflows wird kurz nach dem Stable-Release eingeführt. Nie wieder verlorene Arbeit durch vergessene Klicks auf "Speichern". Das Feature klingt einfach, ist es aber im Hintergrund nicht.

Fazit

Der Schritt zu n8n 2.0 ist ein wichtiger Meilenstein, der vor allem in puncto Sicherheit und Stabilität Verbesserungen bringt. Wer komplexe Setups betreibt, sollte die Zeit bis zum Release nutzen, um seine docker-compose Konfiguration anzupassen und die Migrations-Tools zu nutzen.

So ein richtiges Fazit kann es jetzt auch noch nicht geben da die Version ja noch nicht da ist.
Ich bin gespannt auf den 8. Dezember!