n8n vs Zapier vs Make: Der ehrliche Vergleich 2026 für Unternehmen

Sagen wir gleich zu Beginn, worauf das hier hinausläuft. Wenn Sie ein Unternehmen mit 50 bis 250 Mitarbeitern betreiben, sensible Geschäftsdaten verarbeiten und nicht bereit sind, Ihre gesamte Prozessautomatisierung einem US-amerikanischen SaaS-Anbieter zu überlassen, dann endet dieser Vergleich bei n8n. Nicht weil n8n fehlerfrei wäre. Sondern weil die Alternativen in bestimmten Dimensionen schlicht inakzeptabel sind.

Damit wäre der Artikel allerdings zu kurz geraten. Wir gehen alle drei Plattformen durch: Architektur, Kostenstruktur, DSGVO-Compliance, Integrations-Ökosystem, die tatsächliche Skalierbarkeit und das, was kein Anbieter auf seine Preisseite schreibt, nämlich Vendor-Lock-in. Und zwar mit realen Konfigurationsbeispielen statt Hochglanz-Versprechen. Wenn Sie n8n nicht selbst betreiben möchten: Als n8n Experte in Deutschland übernehmen wir Konzeption, Hosting und Betrieb.

Die Ausgangslage 2026: Warum dieser Vergleich neu geführt werden muss

Automatisierungstools sind längst kein Nice-to-have mehr. Ein typischer Mittelstandsbetrieb synchronisiert heute CRM-Daten mit ERP-Systemen, triggert Rechnungsworkflows aus eingehenden E-Mails, leitet Support-Tickets weiter und verarbeitet Webhook-Events von Zahlungsanbietern, und das alles ohne Entwicklereingriff. Laut Gartner werden bis Ende 2026 über 69 % der Routineaufgaben in mittleren Unternehmen durch Low-Code-Automatisierung abgedeckt (Gartner, Magic Quadrant for Integration Platform as a Service, 2025).

Drei Anbieter dominieren dieses Segment. Zapier (gegründet 2011, aktuell >7.000 native Integrationen), Make (ehemals Integromat, seit 2022 umbenannt, Hauptsitz Prag) und n8n (Open Source, AGPL-3.0, gegründet 2019 in Berlin).

Zwischen 2022 und 2026 hat sich technologisch erstaunlich viel getan. KI-gestützte Workflows, native LLM-Nodes, MCP-Integration und komplexe Branching-Logik sind keine Nischenfunktionen mehr. Genau das verschiebt die Gewichte in diesem Vergleich.

Schnellübersicht: Die drei Plattformen auf einen Blick

n8n: Self-Hosted Automatisierung mit Enterprise-DNA

Architektur

n8n ist eine Node.js-Anwendung, die als Docker-Container, Kubernetes-Pod oder als managed Cloud-Instanz läuft. Die Workflows werden als JSON-Dokumente gespeichert und sind damit vollständig versionierbar. Genau hier liegt der entscheidende Unterschied zu allen Wettbewerbern: Ihre Automationslogik liegt in Ihrer Infrastruktur, in Ihren Git-Repositories, unter Ihrer Kontrolle.

Die Execution Engine arbeitet event-driven. Jeder Node verarbeitet ein Array von Items (INodeExecutionData[]), was Bulk-Processing ohne Schleifenkonstrukte ermöglicht. Python-Node und JavaScript-Node laufen im selben Prozesskontext, ganz ohne Sandbox-Overhead.

Praxisbeispiel: Rechnungseingang automatisieren

Ein Workflow, wie er im Mittelstand ständig vorkommt: Eingehende E-Mails mit PDF-Anhang werden per IMAP getriggert, das PDF wandert an ein OCR-Endpoint, die Rechnungsdaten werden extrahiert und direkt in DATEV oder SAP geschrieben. In n8n sieht der Python-Code-Node dafür so aus:

# n8n Code Node (Python) - Rechnungsdaten normalisieren
import re
from datetime import datetime

items = _input.all()
results = []

for item in items:
    raw = item.json.get("ocr_text", "")

    # Betrag extrahieren (DE-Format: 1.234,56 €)
    amount_match = re.search(r"(\d{1,3}(?:\.\d{3})*(?:,\d{2}))\s*€", raw)
    amount_raw = amount_match.group(1) if amount_match else None

    # Konvertierung in float
    amount_float = None
    if amount_raw:
        amount_float = float(amount_raw.replace(".", "").replace(",", "."))

    # Rechnungsdatum
    date_match = re.search(r"(\d{2})\.(\d{2})\.(\d{4})", raw)
    invoice_date = None
    if date_match:
        d, m, y = date_match.groups()
        invoice_date = datetime(int(y), int(m), int(d)).isoformat()

    results.append({
        "json": {
            "amount": amount_float,
            "invoice_date": invoice_date,
            "raw_vendor": re.search(r"Lieferant:\s*(.+)", raw, re.I).group(1).strip()
                          if re.search(r"Lieferant:", raw, re.I) else None,
            "needs_review": amount_float is None or invoice_date is None
        }
    })

return results

Dieser Code läuft auf Ihrer Infrastruktur. Er verlässt nie Ihr Netzwerk. Kein US-amerikanisches Unternehmen verarbeitet Ihre Lieferantendaten.

Docker-Deployment: Produktionskonfiguration

Eine saubere docker-compose.yml für n8n im Unternehmenseinsatz, rootless-kompatibel, mit PostgreSQL als Backend und Redis für den Queue-Mode:

# docker-compose.yml - n8n Enterprise Self-Hosted
version: "3.8"

services:
  n8n:
    image: n8nio/n8n:1.47.0
    restart: unless-stopped
    user: "1000:1000"
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n_user
      - DB_POSTGRESDB_PASSWORD_FILE=/run/secrets/postgres_password
      - N8N_ENCRYPTION_KEY_FILE=/run/secrets/n8n_encryption_key
      - N8N_PROTOCOL=https
      - N8N_HOST=automation.ihr-unternehmen.de
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_LOG_LEVEL=info
      - N8N_METRICS=true
    volumes:
      - n8n_data:/home/node/.n8n
    secrets:
      - postgres_password
      - n8n_encryption_key
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    user: "1000:1000"
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n_user
      POSTGRES_PASSWORD_FILE: /run/secrets/postgres_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    secrets:
      - postgres_password
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n_user -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    user: "1000:1000"
    command: redis-server --requirepass "${REDIS_PASSWORD}"
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  n8n_data:
  postgres_data:
  redis_data:

secrets:
  postgres_password:
    file: ./secrets/postgres_password.txt
  n8n_encryption_key:
    file: ./secrets/n8n_encryption_key.txt

Anmerkung zu Secrets: Verwenden Sie niemals Klartext-Passwörter in docker-compose.yml. Docker Secrets oder ein Vault-Backend (HashiCorp Vault, Bitwarden Secrets Manager) sind Pflicht.

Kostenstruktur n8n

Die Community-Edition ist kostenlos. Die Enterprise-Edition (ab 500 $/Monat, Jahresvertrag) schaltet SAML/SSO, Audit-Logs, erweiterte Benutzerberechtigungen und SLA-Support frei. Für die meisten Mittelständler mit einer dedizierten IT reicht die Community-Edition plus eigenem Betrieb vollkommen aus.

Rechnen wir das konkret durch, für 50.000 Workflow-Ausführungen pro Monat. n8n self-hosted auf einem Hetzner CX31 mit 8 GB RAM kostet rund 12 €/Monat Server plus 0 € Lizenz, also 12 €/Monat. n8n Cloud im Starter-Tarif liegt bei 20 $/Monat, deckt aber nur 2.500 Executions ab und skaliert damit nicht. Zapier Professional schlägt mit ca. 73 $/Monat für 50.000 Tasks zu Buche, Make Teams mit ca. 29 $/Monat für 40.000 Operations (gerundete Pakete, der Overage wird schnell teuer).

Der Break-Even zwischen n8n self-hosted und Zapier liegt, Betriebsaufwand mitgerechnet, bei wenigen hundert Ausführungen pro Monat.

Zapier: Marktführer mit strukturellen Schwächen für Enterprise

Was Zapier gut macht

Zapier ist in der No-Code-Welt das, was Salesforce im CRM-Bereich ist: allgegenwärtig, tief in die tägliche Arbeit von Business-Teams integriert und mit einem Ökosystem, das schwer zu übertreffen ist. Über 7.000 native App-Integrationen, vorgefertigte Zap-Templates für praktisch jeden Use Case und ein Editor, den auch nicht-technische Mitarbeiter ohne Schulung bedienen können.

Für kleine Teams mit begrenzter IT-Kapazität ist das ein echtes Argument.

Wo Zapier für den Mittelstand scheitert

Beginnen wir mit der Datenhoheit. Alle Workflow-Daten laufen über Zapiers US-Server, und Zapier Inc. unterliegt dem US Cloud Act. Im Klartext: Wenn US-Behörden Zugriff auf Zapier-Serverdaten anfordern, kann Zapier diese Anfrage nicht ablehnen, völlig unabhängig davon, ob Ihre Daten DSGVO-relevant sind. Für Unternehmen, die personenbezogene Daten, Finanzdaten oder Geschäftsgeheimnisse in Workflows verarbeiten, ist das ein strukturelles Problem, das auch kein DPA (Data Processing Agreement) löst.

Dann die Pricing-Eskalation. Zapier rechnet nach "Tasks" ab, und jede Aktion in einem Zap kostet einen Task. Multi-Step-Workflows mit Filter-Nodes, Formatter-Steps und Lookup-Tables vervielfachen den Task-Verbrauch in Windeseile. Ein Workflow, der 1.000 Datensätze pro Tag verarbeitet und dabei 8 Steps durchläuft, verbraucht 8.000 Tasks täglich, das sind 240.000 Tasks pro Monat. Im Zapier-Professional-Plan landen Sie damit bei ca. 400 $/Monat. Ohne Vorwarnung.

Hinzu kommt die fehlende Code-Flexibilität an den kritischen Stellen. Der Zapier Code-Step unterstützt nur JavaScript, weder Python noch Shell. Der Zugriff auf externe Libraries ist stark eingeschränkt. Komplexe Datentransformationen, die in der Buchhaltung oder im ERP-Umfeld zum Alltag gehören, erfordern entweder Workarounds oder externe API-Calls.

Am schwersten wiegt aber der Lock-in durch das proprietäre Format. Zapier-Workflows existieren ausschließlich als proprietäre Konfiguration in Zapiers Datenbank. Kein Export in ein offenes Format, keine Git-Versionierung, kein Review-Prozess. Wenn Zapier Ihren Account sperrt, die Preise verdoppelt oder den Dienst einstellt, haben Sie nichts in der Hand.

Und das ist kein hypothetisches Szenario. Zapier hat seine Preise zwischen 2021 und 2024 mehrfach erhöht und das Grandfathering für bestehende Pläne schrittweise abgebaut.

Make: Der technische Mittelweg mit europäischen Wurzeln

Positionierung und Architektur

Make (früher Integromat) wurde 2012 in Prag gegründet und ist heute Teil der Celonis-Gruppe. Das visuelle Interface ist deutlich mächtiger als das von Zapier. Workflows werden als Datenflussgraphen dargestellt, mit explizitem Routing, Iterator-Modulen, Aggregatoren und einem Fehlerbehandlungssystem, das Zapier klar hinter sich lässt.

Make bietet außerdem eine EU-Datenregion an. Das löst das gröbste DSGVO-Problem, jedenfalls solange Celonis als europäisches Unternehmen operiert und keine Übernahme durch einen US-Konzern stattfindet. Dieses Risiko bleibt real, daran führt kein Weg vorbei.

Stärken gegenüber Zapier

Drei Punkte sprechen klar für Make. Erstens die szenario-basierte Abrechnung: Make rechnet nach "Operations" ab, wobei Filter-Module anders als bei Zapier keine Operations verbrauchen. Für komplexe Workflows mit viel Conditional Logic ist das spürbar günstiger. Zweitens die komplexere Workflow-Logik, denn Router, Error Handler, Iterator und Aggregator sind native Konzepte und machen Make für anspruchsvollere Prozesse tauglich. Und drittens die bessere API-Integration über ein HTTP-Modul mit voller Header-Kontrolle, OAuth2-Flows und Webhook-Response-Manipulation.

Schwächen im Enterprise-Einsatz

Make ist kein Self-Hosted-Produkt, und eine offiziell unterstützte On-Premises-Version existiert nicht. Die angebotene EU-Region reduziert das Risiko, eliminiert es aber nicht.

Das JavaScript-Code-Modul ist ähnlich stark eingeschränkt wie bei Zapier, und eine Python-Ausführung ist gar nicht erst vorgesehen. Auch ein natives Git-Backend für die Workflow-Versionierung fehlt. Szenarien lassen sich zwar als Blueprints (JSON) exportieren, aber das ist kein echter Versionierungsworkflow.

Reale Kostenrechnung für denselben Use Case (50.000 Ausführungen/Monat):

Make Teams kostet 29 $/Monat für 40.000 Operations, der Overage liegt bei ca. 9 $ für 10.000 zusätzliche Operations, macht zusammen 38 $/Monat. Nicht schlecht. Nur liegen die Daten eben auf einem fremden Server.

DSGVO-Compliance: Der Vergleich, den Anbieter nicht führen wollen

Genau hier haben aus meiner Erfahrung viele IT-Leiter einen blinden Fleck. "Wir haben ein DPA unterzeichnet" ist keine ausreichende Antwort. Ein Data Processing Agreement verschiebt die Verantwortlichkeit, aber es verhindert keinen Datenzugriff durch US-Behörden.

Für Unternehmen in regulierten Branchen (Finanzdienstleistungen, Gesundheitswesen, öffentlicher Sektor) ist n8n self-hosted die einzige Option, die einen DSGVO-Audit ohne strukturelle Lücken besteht.

Integrations-Ökosystem: Zahlen und Realität

Zapier führt mit über 7.000 nativen Integrationen, was zunächst beeindruckend klingt. In der Praxis sind für den typischen Mittelstandsbetrieb aber maximal 20 bis 30 Integrationen wirklich relevant. Und die entscheidenden Systeme, also SAP, DATEV, Lexware, spezifische ERP-Systeme und branchenspezifische Software, sind bei keinem der drei Anbieter vollständig nativ integriert.

Damit verliert die nackte Integrationszahl ihren Glanz. Was zählt, ist die HTTP-Request-Flexibilität: Kann ich beliebige REST-APIs anbinden? Kann ich SOAP-Webservices transformieren? Kann ich benutzerdefinierte Auth-Flows (OAuth2, API-Key, Certificate-based) umsetzen?

Bei n8n lautet die Antwort durchweg ja: vollständige HTTP-Flexibilität, Custom Nodes via npm-Packages, dazu ein Community-Node-Repository mit über 400 Community-Nodes (Stand Mai 2026). Zapier erlaubt HTTP-Requests über "Webhooks by Zapier", die Authentifizierungsoptionen sind aber begrenzt, und eine eigene App-Integration setzt einen Zapier-Plattform-Account voraus. Make wiederum punktet mit einem starken HTTP-Modul, guter OAuth2-Unterstützung und Custom Apps über das Make-Entwicklerportal.

Beim Dauerbrenner SAP zeigt sich das exemplarisch. Keine der drei Plattformen bringt eine native, produktionsreife SAP-Integration mit. Die Lösung ist immer ein HTTP-Modul gegen SAPs REST-APIs oder ein Middleware-Layer. Und hier ist n8n durch die Python-Nodes und die Möglichkeit, produktionsreifen Code direkt auszuführen, schlicht flexibler.

AI-Workflows 2026: Wer ist wirklich ready?

Das ist das Thema, das den Markt 2025 und 2026 geprägt hat. Alle drei Anbieter haben KI-Funktionen integriert, doch die Qualität klafft erheblich auseinander.

n8n: Native LLM-Nodes für OpenAI, Anthropic Claude, Google Gemini und Ollama (lokal), dazu eine LangChain-Integration. Es gibt einen MCP-Client-Node (seit n8n 1.35) für das Model Context Protocol, einen Agent-Node mit Tool-Calling und workflow-basiertes RAG mit Pinecone-, Qdrant- und Weaviate-Nodes. Technisch ist das aktuell die Spitze.

Wie weit n8n hier ist, zeigt ein Beispiel aus dem Alltag: Ein Workflow liest eingehende Support-E-Mails, klassifiziert sie über ein lokales Ollama-Modell (kein Datenaustausch mit externen APIs), bestimmt die Priorität und legt das Ticket automatisch in Ihrem System an. Vollständig on-premises, ohne dass eine einzige Zeile Ihrer Kundendaten das Netzwerk verlässt.

{
  "nodes": [
    {
      "name": "Email Trigger",
      "type": "n8n-nodes-base.emailReadImap",
      "parameters": {
        "mailbox": "support@ihr-unternehmen.de",
        "format": "resolved"
      }
    },
    {
      "name": "Klassifizierung via Ollama",
      "type": "@n8n/n8n-nodes-langchain.lmChatOllama",
      "parameters": {
        "model": "llama3.2:3b",
        "baseUrl": "http://ollama.intern:11434",
        "prompt": "Klassifiziere diese Support-Anfrage in: [kritisch, hoch, mittel, niedrig]. Antworte nur mit dem Prioritätslevel.\n\nAnfrage: {{ $json.text }}"
      }
    }
  ]
}

Zapier: "Zapier AI" ermöglicht eine natürlichsprachliche Zap-Erstellung und einfache LLM-Calls via OpenAI. Für simple Use Cases reicht das. Für agentic Workflows mit Tool-Use und lokalem LLM-Betrieb taugt es nicht.

Make: "Make AI" liegt auf einem ähnlichen Niveau wie Zapier, mit OpenAI-Integration und Text-Manipulation. Lokales LLM-Support oder MCP sucht man vergeblich.

Performance und Skalierbarkeit: Benchmarks

Diese Zahlen basieren auf internen Tests im Rahmen von Kundenprojekten bei NextGen IT (Testumgebung: Hetzner CX41, 16 GB RAM, 4 vCPU, Debian 12, n8n 1.47.0 im Queue-Mode mit 4 Worker).

SaaS-Anbieter drosseln mit Absicht, denn ihr Geschäftsmodell lebt von Volume-Paketen. n8n auf Ihrer eigenen Hardware kennt diese künstliche Begrenzung schlicht nicht.

Vendor-Lock-in: Die versteckten Kosten

Das ist das Thema, über das niemand redet, bis es zu spät ist.

Bei Zapier existiert Ihre gesamte Automatisierungslogik als proprietäre Konfiguration auf Zapiers Servern. Haben Sie nach drei Jahren 200 Zaps aufgebaut und Zapier verdoppelt die Preise, bleiben Ihnen genau zwei Optionen: zahlen oder alles neu bauen. Einen Export oder eine Portierbarkeit gibt es nicht.

Dazu kommen drei weitere Lock-in-Dimensionen, die gerne übersehen werden. Da ist zunächst die kognitive Abhängigkeit: Ihr Team lernt Zapier-Konzepte (Zap, Trigger, Action), nicht generische Automatisierungskonzepte, und dieses Wissen ist nicht übertragbar. Hinzu kommt ein Integrations-Lock-in, denn einige Zapier-Integrationen nutzen Zapier-spezifische API-Zugänge, die sich außerhalb von Zapier nicht reproduzieren lassen. Und schließlich der Prozess-Lock-in: Sind Workflows weder dokumentiert noch versioniert, verliert das Unternehmen das institutionelle Wissen über die eigenen Prozesse. Bei einem Anbieterwechsel oder dem Abgang eines Mitarbeiters ist dieses Wissen einfach weg.

n8n-Workflows sind dagegen JSON-Dokumente, die in Ihrem Git-Repository liegen, und jede Änderung ist nachvollziehbar. Sollte n8n morgen aufhören zu existieren (das Unternehmen ist profitabel und wächst kräftig, aber nehmen wir es einmal hypothetisch an), exportieren Sie Ihr JSON und bauen die Logik in einem anderen System nach. Die Prozesse sind dokumentiert, die Daten liegen bei Ihnen.

Migrationspfade: Was ein Wechsel kostet

Von Zapier zu n8n

Für einfache Trigger-Action-Zaps ist die Migration überschaubar. Bei komplexen Multi-Step-Workflows mit Zapier-spezifischen Built-in-Apps (Formatter, Filter, Delay) sollten Sie dagegen mit 2 bis 4 Stunden pro Workflow für Dokumentation und Neuimplementierung rechnen.

Ein dringender Rat: Exportieren Sie sofort alle Zap-Konfigurationen als Screenshots oder Dokumentation, denn einen maschinenlesbaren Export bietet Zapier nicht. Das sollten Sie ohnehin heute tun, ganz unabhängig von einer Migrationsentscheidung.

Von Make zu n8n

Make bietet immerhin Blueprint-Exports als JSON. Das Format ist proprietär, aber strukturiert genug für eine semi-automatische Konvertierung. Es existieren auch Community-Tools für die Make-zu-n8n-Migration (GitHub: make-to-n8n-converter und verschiedene Community-Beiträge). Trotzdem kommen Sie um eine manuelle Anpassung pro Workflow nicht herum.

Migrations-Checkliste

1. Alle aktiven Workflows dokumentieren (Trigger, Schritte, Business-Logik, Fehlerverhalten)
2. Abhängige Credentials und API-Keys inventarisieren
3. Priorität festlegen, kritische Workflows zuerst
4. Parallelbetrieb für 2 bis 4 Wochen planen (Dual-Run)
5. Monitoring auf beiden Systemen einrichten, um Divergenzen zu erkennen
6. Das alte System erst nach verifizierter Funktionalität sukzessive abschalten

Entscheidungsmatrix: Welches Tool für welchen Kontext?

Legende: ✅ = geeignet, ⚠️ = bedingt geeignet, ❌ = nicht geeignet

Die ehrliche Empfehlung

Für den deutschen Mittelstand mit einer internen IT (und sei es nur eine einzelne Person), mit Datenverarbeitungsprozessen, die unter die DSGVO fallen, und mit einem Planungshorizont jenseits der 24 Monate lautet meine Empfehlung klar: n8n self-hosted.

Die initialen Mehrkosten für Server-Setup, erste Konfiguration und die Einarbeitung der Mitarbeiter amortisieren sich gegenüber Zapier typischerweise innerhalb von 6 bis 12 Monaten. Danach wächst die Kostenstruktur linear mit Ihrer Infrastruktur, nicht exponentiell mit Ihrem Automatisierungsvolumen.

Zapier ist sinnvoll, wenn Ihr Unternehmen keine eigene IT hat, ausschließlich unkritische Daten automatisiert und die Einstiegsgeschwindigkeit über allem steht. Planen Sie dann aber von Anfang an einen Migrationspfad für den Moment ein, in dem Automatisierung geschäftskritisch wird.

Make ist ein gangbarer Kompromiss, wenn Sie eine EU-Datenresidenz akzeptieren, nicht selbst hosten wollen und komplexere Workflows brauchen, als Zapier sie bietet. Das M&A-Risiko sollten Sie dabei im Hinterkopf behalten.

Was Sie morgen tun können

1. Inventarisieren Sie Ihre bestehenden Zapier- und Make-Workflows, und zwar heute, bevor etwas verloren geht.
2. Richten Sie eine n8n-Testinstanz auf einem Hetzner-Server ein. Die oben gezeigte docker-compose.yml ist in 30 Minuten produktionsbereit.
3. Migrieren Sie einen unkritischen Workflow als Proof of Concept.
4. Definieren Sie Ihre Daten-Sensitivitätsstufen. Was darf die Unternehmensgrenze unter keinen Umständen verlassen?

Automatisierung ist am Ende keine Werkzeugfrage, sondern eine Architekturfrage. Und Architekturen, die auf fremden Servern laufen, über die Sie keine Kontrolle haben, sind fragile Architekturen.

Weiterführende Ressourcen

• n8n-Dokumentation: docs.n8n.io (Community-Nodes, Self-Hosting-Guide, Queue-Mode-Konfiguration)
• n8n GitHub: github.com/n8n-io/n8n (Issues, Roadmap, Community-Nodes-Verzeichnis)
• Gartner, Magic Quadrant for Integration Platform as a Service, Worldwide, Oktober 2025
• BSI-Grundschutz-Kompendium 2025, Baustein CON.2 (Datenschutz), Bundesamt für Sicherheit in der Informationstechnik
• Europäisches Datenschutzausschuss, Leitlinien 01/2021 zur Nutzung von Cloud-Diensten durch den öffentlichen Sektor (anwendbar als Referenz für private Unternehmen)

Niklas ist Backend Engineer bei NextGen IT und betreut die Automatisierungsinfrastruktur von Mittelstandskunden in DACH. Dieser Artikel spiegelt praktische Erfahrungen aus produktiven Deployments wider.