Warum n8n, warum jetzt — Prolog zur Einstiegs-Reihe

Prolog · Serie: Einstieg in n8n

Am 12. Mai 2026 hat SAP auf der Sapphire-Konferenz eine strategische Investition in n8n bekannt gegeben. Die Bewertung des Berliner Workflow-Spezialisten verdoppelte sich auf 5,2 Milliarden Dollar, SAP hält knapp 1,3 Prozent. Wichtiger als die Zahl ist der zweite Teil: n8n wird nativ in Joule Studio eingebettet, SAPs Umgebung für agentische KI-Anwendungen. Zwei Wochen vorher hatte Mercedes-Benz angekündigt, n8n als globale Automatisierungsplattform über alle Geschäftsbereiche auszurollen. Diese Reihe nimmt beide Ereignisse zum Anlass, n8n von Grund auf aufzuarbeiten: was es ist, wie man es selbst betreibt, und wo es in eine bestehende Enterprise-Landschaft passt.

Von der Self-Hoster-Nische zur Enterprise-Schicht

n8n wurde 2019 in Berlin gegründet und galt jahrelang als der quelloffene Gegenentwurf zu Zapier und Make: eine selbst hostbare Workflow-Engine mit visuellem Editor, großer Konnektor-Sammlung und der Möglichkeit, eigene Knoten zu schreiben. Enterprise-Software war n8n damit nicht. Die meisten Konzerne haben das Werkzeug bestenfalls als nettes Tool für Marketing-Automation wahrgenommen.

Mit dem SAP-Deal ändert sich diese Wahrnehmung. n8n bekommt einen prominenten Platz innerhalb der SAP Business AI Platform, und ein Werkzeug, das in deutschen Berater-Setups als „kleine Lösung" galt, wird für Architekturentscheidungen relevant, die vor sechs Monaten anders ausgesehen hätten.

n8n ist nicht der Gegner von AIF

Ein häufiges Missverständnis liegt darin, n8n als Ersatz für klassische SAP-Integrationswerkzeuge zu betrachten. AIF, das Application Interface Framework im S/4-Backend, überwacht Nachrichten zwischen SAP-internen und externen Systemen, liefert fachliche Recovery-Mechanismen und Compliance-getriebenes Audit-Logging. Es ist für Szenarien gebaut, in denen ein verlorener Beleg ein Compliance-Problem ist.

n8n bedient eine andere Schicht. Es orchestriert über Systeme hinweg, oft vor oder hinter dem SAP-Backend, in Kombination mit Cloud-Diensten, REST-APIs, Datenbanken und LLMs. Wo AIF die Integrität einer Nachricht innerhalb der SAP-Welt sichert, baut n8n den Prozess drum herum. Die beiden Werkzeuge schließen sich nicht aus, sie ergänzen sich. Genau diese Trennung wird im Brücken-Artikel am Schluss der Reihe konkret.

Souveränität als Auswahlkriterium

Bemerkenswert am Mercedes-Beispiel ist die explizite Begründung der Auswahl. Mercedes-Benz nennt die Frage der digitalen Souveränität als einen der zentralen Gründe: Da n8n selbst gehostet und Cloud-unabhängig betrieben werden kann, behält Mercedes-Benz die volle Kontrolle über kritische Daten und Arbeitsabläufe. In der englischsprachigen Pressemitteilung ist dieselbe Aussage explizit ein „commitment to digital sovereignty and open architecture".

Das ist keine PR-Aussage. Für ein Unternehmen, das in mehreren Regionen mit unterschiedlichen Datenschutzregimes operiert, ist die Frage, wo Workflows laufen und wo Daten verarbeitet werden, eine harte Architekturentscheidung. n8n ist unter Fair-Code-Lizenz veröffentlicht. Das heißt: der Quellcode ist offen, Self-Hosting ist explizit erlaubt, und die Plattform läuft auf eigener Infrastruktur ohne Cloud-Abhängigkeit. Das ist genau der Punkt, an dem klassische SaaS-Automation-Werkzeuge wie Zapier oder Make für einen Konzern wie Mercedes-Benz nicht funktionieren: Daten müssen das Unternehmen nicht verlassen, damit ein Workflow läuft.

Die Fair-Code-Lizenz ist dabei nicht zu verwechseln mit klassischer Open-Source-Lizenzierung im OSI-Sinn, weil kommerzielle Wiederverkäufer Beschränkungen haben. Für den produktiven Einsatz im eigenen Haus ist das aber irrelevant: Wer n8n selbst hostet und intern nutzt, hat alle Freiheiten. Diese Reihe wird n8n konsequent self-hosted aufsetzen, auch dort wo eine n8n-Cloud-Variante einfacher wäre.

n8n im Spektrum der Integrationswerkzeuge

Um n8n richtig einzuordnen, hilft ein kurzer Blick auf die Nachbarschaft. Vier Kategorien sind relevant, in jeder davon hat n8n einen anderen Platz:

Diese Tabelle ist bewusst grob. Die spannende Beobachtung ist, dass n8n in jeder dieser Kategorien irgendwo einen Fuß hat, ohne in einer davon vollständig zu landen. Genau das macht es interessant für Szenarien, in denen klassische Workflow-Engines zu schwergewichtig, SaaS-Automation zu eingeschränkt und reine Code-Frameworks zu pflegeintensiv wären.

Workflow, Knoten, Items

Auf der Ebene der Konzepte ist n8n schnell beschrieben. Ein Workflow besteht aus Knoten (Nodes), die über Verbindungen (Connections) miteinander verkettet sind. Jeder Workflow startet mit einem Trigger, etwa einem Webhook, einem Zeitplan, einem Datenbankereignis oder einem manuellen Aufruf. Daten fließen als Items durch den Workflow, wobei jeder Knoten ein Array von Items empfängt, verarbeitet und ein Array von Items ausgibt. Dieses Item-Modell ist eine der zentralen Eigenheiten von n8n und ein häufiger Stolperstein für Einsteiger, die ein einzelnes JSON-Objekt erwarten.

Knoten gibt es in mehreren Sorten. Es gibt Integrationsknoten für konkrete Dienste (Slack, GitHub, Salesforce, Postgres, SAP über HTTP), generische Knoten wie HTTP-Request und Webhook, Transformationsknoten wie Set, Code (mit JavaScript oder Python) und Switch, und AI-spezifische Knoten wie den AI Agent, der ein LLM mit Tools, Memory und strukturiertem Output kombiniert. Der AI-Agent-Knoten ist der direkte Berührungspunkt zur agentischen Welt. Das ist auch der Grund, warum der SAP-Deal überhaupt stattgefunden hat.

Hinter der Oberfläche steht eine Node.js-Anwendung, die Workflows als JSON speichert, Ausführungen in einer Datenbank protokolliert und ab Version 2.0 die einzelnen Knoten in einer isolierten Task-Runner-Sandbox ausführt. Das macht n8n in seiner aktuellen Form deutlich produktionstauglicher als noch vor einem Jahr, und diese Reihe wird die 2.x-Architektur konsequent voraussetzen.

Neun Artikel, ein Demo-Projekt

Die Reihe ist ein praktischer Einstieg, kein Marketing-Briefing. Pro Artikel wird ein konkretes Stück gebaut, das in einem öffentlichen Codeberg-Repo nachvollziehbar wird. Vom ersten Container über das eigene Hosting mit Postgres und Caddy, einen synthetischen Testdatensatz für Support-Tickets, regelbasierte und AI-gestützte Klassifikation bis zur SAP-Anbindung und dem produktiven Betrieb mit Queue-Mode und Observability. Neun Artikel, plus diesen Prolog.

Das Demo-Projekt ist eine Vorklassifikation für Support-Tickets. Eingehende Tickets werden nach Kategorie, Sprache und Dringlichkeit eingeordnet und an die richtige Stelle geroutet. Das ist ein bewusst alltägliches Szenario, in dem fast jede Beratungsfirma und jede interne IT-Abteilung sich wiederfindet. Es ist auch ein gutes Trainingsfeld, weil es alle relevanten n8n-Bausteine durchspielt: Eingang über Webhook, Datenanreicherung, klassische Logik, LLM-Klassifikation, Fehlerbehandlung, Eskalation, Logging.

Das wird die umfangreichste Reihe bisher auf rotecodefraktion.de, mit neun Artikeln, einem eigenen Repo mit Tests und CI, einem BTP-Service als SAP-Stellvertreter und mehr Werkzeugen im Spiel als in den Vorgänger-Reihen. Beim Start sind mehrere Stellen bewusst offen: Joule-Studio-Verfügbarkeit, n8n 2.x-Entwicklung, BTP-Konsolen-Änderungen. Wo das Projekt nach neun Artikeln steht, lässt sich heute nicht vollständig vorhersagen. Das ist der Teil, der mich am meisten interessiert.

Mitmachen

Der Code zur Reihe lebt auf Codeberg unter rotecodefraktion/n8n-einstieg. Pro Artikel gibt es einen Tag, der genau den Stand am Ende des Artikels markiert: v0.1 nach dem Überblick, v0.2 nach dem Self-Hosting-Setup und so weiter, bis v1.0 am Ende der Reihe. Wer mitmachen will, klont das Repo, checkt den Tag des aktuellen Artikels aus und hat damit genau die Datei-Stände, die der Artikel beschreibt.

Das Setup läuft mit Docker Compose, Postgres als Datenbank und Caddy als Reverse Proxy mit automatischem HTTPS. Vorausgesetzt wird ein Linux- oder macOS-System mit Docker und Git, alles weitere installiert das Compose-Setup selbst. Wer Apple Silicon hat, ist gut bedient, weil später der Generator für Testdaten auch lokale LLMs nutzt, was API-Kosten spart und die Reihe von Cloud-Diensten unabhängiger macht.

Der nächste Artikel: n8n im Überblick

Artikel 1 geht auf die technische Architektur ein: Editor, Execution Engine, Task Runners, Workflow-Persistenz. Außerdem die Frage, wo n8n im Spektrum zwischen Enterprise-Integration und SaaS-Automation tatsächlich hingehört, und was die Fair-Code-Lizenz im Detail bedeutet. Am Ende von Artikel 1 steht ein initialisiertes Codeberg-Repo mit der Grundarchitektur und einem ersten README, Tag v0.1.