Why n8n, why now — Prologue to the Getting-Started Series
Prologue · Series: Getting Started with n8n
On May 12, 2026, SAP announced a strategic investment in n8n at its Sapphire conference. The Berlin-based workflow specialist’s valuation doubled to $5.2 billion; SAP holds just under 1.3 percent. More important than the number is the second part: n8n will be natively embedded in Joule Studio, SAP’s environment for agentic AI applications. Two weeks earlier, Mercedes-Benz announced it would roll out n8n as a global automation platform across all business areas. This series takes both events as a starting point and works through n8n from the ground up: what it is, how to run it yourself, and where it fits into an existing enterprise landscape.
From self-hoster niche to enterprise layer
n8n was founded in Berlin in 2019 and for years was seen as the open-source counterpart to Zapier and Make: a self-hostable workflow engine with a visual editor, a large connector library, and the option to write your own nodes. Enterprise software it was not. Most corporates regarded the tool at best as a nice helper for marketing automation.
The SAP deal changes that perception. n8n gets a prominent place inside the SAP Business AI Platform, and a tool that German consultancies treated as a “small solution” suddenly matters for architecture decisions that would have looked different six months ago.
n8n is not AIF’s opponent
A common misunderstanding is to view n8n as a replacement for classic SAP integration tools. AIF, the Application Interface Framework inside the S/4 backend, monitors messages between SAP-internal and external systems, provides functional recovery mechanisms, and handles compliance-driven audit logging. It is built for scenarios where a lost document is a compliance problem.
n8n addresses a different layer. It orchestrates across systems, often in front of or behind the SAP backend, combined with cloud services, REST APIs, databases, and LLMs. Where AIF guarantees the integrity of a message inside the SAP world, n8n builds the process around it. The two tools do not exclude each other; they complement each other. This distinction will become concrete in the bridge article at the end of the series.
Sovereignty as a selection criterion
What stands out about the Mercedes case is the explicit reasoning behind the choice. Mercedes-Benz names digital sovereignty as one of the central reasons: because n8n can be self-hosted and run independently of cloud providers, Mercedes-Benz retains full control over critical data and workflows. The English-language press release frames the same point as a “commitment to digital sovereignty and open architecture.”
This is not a PR line. For a company operating across multiple regions with different data protection regimes, the question of where workflows run and where data is processed is a hard architectural decision. n8n is published under a Fair-Code license. That means: the source code is open, self-hosting is explicitly permitted, and the platform runs on your own infrastructure without cloud dependency. This is precisely the point where classic SaaS automation tools like Zapier or Make do not work for a company like Mercedes-Benz: data does not need to leave the company for a workflow to run.
The Fair-Code license should not be confused with classic open-source licensing in the OSI sense, because commercial resellers face restrictions. For productive in-house use, however, this is irrelevant: anyone self-hosting n8n internally has all the freedoms they need. This series will set up n8n self-hosted throughout, even where the n8n Cloud variant would be simpler.
n8n in the spectrum of integration tools
To place n8n correctly, a quick look at the neighborhood helps. Four categories are relevant; n8n has a different position in each:
| Category | Examples | Where n8n stands |
|---|---|---|
| SaaS Automation | Zapier, Make, Pipedream | Functionally similar, but self-hosted instead of cloud-only, free instead of per-workflow |
| Enterprise Integration | SAP CPI, AIF, MuleSoft, Boomi | Complementary rather than competing; n8n as orchestration, CPI/AIF as SAP-internal recovery layer |
| Workflow Engines | Apache Airflow, Prefect, Dagster | Different domain (data engineering, batch pipelines); n8n is event-driven and UI-centric |
| Agent Frameworks | LangGraph, CrewAI, AutoGen | n8n combines classic workflow logic with AI agent nodes and positions itself between the two worlds |
The table is deliberately coarse. The interesting observation is that n8n has a foot in each of these categories without fully landing in any of them. That is precisely what makes it interesting for scenarios in which classic workflow engines feel too heavyweight, SaaS automation too restrictive, and pure code frameworks too maintenance-intensive.
Workflow, nodes, items
At the level of concepts, n8n is quickly described. A workflow consists of nodes connected by connections. Every workflow starts with a trigger, a webhook, a schedule, a database event, or a manual invocation. Data flows through the workflow as items, with each node receiving an array of items, processing them, and emitting an array of items. This item model is one of n8n’s central peculiarities and a frequent stumbling block for newcomers who expect a single JSON object.
Nodes come in several flavors. There are integration nodes for specific services (Slack, GitHub, Salesforce, Postgres, SAP over HTTP), generic nodes like HTTP Request and Webhook, transformation nodes like Set, Code (JavaScript or Python), and Switch, and AI-specific nodes like the AI Agent, which combines an LLM with tools, memory, and structured output. The AI Agent node is the direct contact point to the agentic world. It is also the reason the SAP deal happened in the first place.
Behind the surface sits a Node.js application that stores workflows as JSON, logs executions to a database, and as of version 2.0 runs individual nodes inside an isolated task-runner sandbox. This makes n8n significantly more production-ready than it was a year ago, and the series will consistently assume the 2.x architecture.
Nine articles, one demo project
The series is a practical introduction, not a marketing briefing. Each article builds a concrete piece that is traceable in a public Codeberg repository. From the first container through self-hosting with Postgres and Caddy, a synthetic test dataset for support tickets, rule-based and AI-driven classification, to SAP integration and production operation with queue mode and observability. Nine articles, plus this prologue.
The demo project is a triage system for support tickets. Incoming tickets are categorized by topic, language, and urgency, and routed to the right place. This is a deliberately everyday scenario in which almost every consultancy and every internal IT department will recognize itself. It is also a good training ground because it exercises all the relevant n8n building blocks: ingestion via webhook, data enrichment, classical logic, LLM classification, error handling, escalation, logging.
This will be the most extensive series on rotecodefraktion.de to date, with nine articles, its own repository with tests and CI, a BTP service as SAP stand-in, and more moving parts than any of the predecessor series. Several points are deliberately open at the start: Joule Studio availability, n8n 2.x development, BTP console changes. Where the project will stand after nine articles cannot be fully predicted today. That is the part I find most interesting.
How to follow along
The code for the series lives on Codeberg under rotecodefraktion/n8n-einstieg. Each article has a tag marking the exact state at the end of that article: v0.1 after the overview, v0.2 after the self-hosting setup, and so on, up to v1.0 at the end of the series. To follow along, clone the repo, check out the tag of the current article, and you have exactly the file states the article describes.
The setup runs on Docker Compose, with Postgres as the database and Caddy as a reverse proxy providing automatic HTTPS. Prerequisites are a Linux or macOS system with Docker and Git; the Compose setup installs everything else. Apple Silicon users are in a good spot, because later articles use local LLMs for test-data generation, which saves API costs and reduces dependency on cloud services.
The next article: n8n at a glance
Article 1 goes into the technical architecture: editor, execution engine, task runners, workflow persistence. It also addresses where n8n actually fits in the spectrum between enterprise integration and SaaS automation, and what the Fair-Code license means in detail. By the end of article 1, there will be an initialized Codeberg repo with the basic architecture and a first README, tag v0.1.