n8n vs. Make: Welches Automatisierungstool passt besser?

Worum es geht — und für wen

n8n und Make (früher Integromat) lösen auf den ersten Blick dasselbe Problem: Sie verbinden deine Systeme — CRM, ERP, E-Mail, Buchhaltung, Webshop — und automatisieren die Abläufe dazwischen, ohne dass für jede Verbindung Individualsoftware entsteht. Beide arbeiten visuell, beide haben große Integrationskataloge, beide können inzwischen KI-Bausteine in Workflows einbetten.

Trotzdem ist die Entscheidung zwischen beiden keine Geschmacksfrage. Die Tools unterscheiden sich an drei Stellen grundlegend: beim Abrechnungsmodell (pro Schritt vs. pro Workflow-Lauf), beim Hosting (nur Cloud vs. auch eigene Infrastruktur) und bei der Frage, wie viel eigene Logik du in Workflows unterbringen kannst. Diese drei Unterschiede entscheiden darüber, was dich das Ganze in zwei Jahren kostet und wer es warten kann.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in kleinen und mittleren Unternehmen, die vor genau dieser Tool-Entscheidung stehen. Er gehört zu unserer Übersicht über Automatisierungstools und Integrationen.

Transparenz vorweg: Ich arbeite in Kundenprojekten überwiegend mit n8n, weil Self-Hosting und Code-Flexibilität für meine typischen B2B-Fälle wichtiger sind als der schnellste Einstieg. Das ist eine Position, kein neutraler Laborbefund — ich begründe sie unten und benenne genauso klar die Fälle, in denen Make die bessere Wahl ist.

Begriffe kurz geklärt

• n8n ist eine Workflow-Automatisierungsplattform unter „Fair-Code”-Lizenz. Es gibt sie als gehostete Cloud-Version und als selbst betreibbare Community Edition, deren Quellcode offen auf GitHub liegt. Workflows bestehen aus Nodes (Knoten), die Daten von Schritt zu Schritt weiterreichen.
• Make ist ein reiner Cloud-Dienst (SaaS). Automatisierungen heißen dort Szenarien und bestehen aus Modulen. Jede Modulausführung verbraucht laut Make-Dokumentation eine Operation bzw. einen Credit — das ist zugleich die Abrechnungseinheit.
• Execution heißt bei n8n ein kompletter Durchlauf eines Workflows. Laut n8n-Preisseite gilt: Eine Execution ist ein einzelner Lauf des gesamten Workflows — unabhängig davon, wie viele Schritte er hat oder wie viele Daten er verarbeitet.
• Self-Hosting bedeutet, die Software auf eigener Infrastruktur zu betreiben (eigener Server, eigene Cloud-VM), statt sie als Dienst beim Anbieter zu mieten.

Abzugrenzen sind beide Tools von RPA (Roboter klicken Benutzeroberflächen durch, wenn keine Schnittstelle existiert) und von Entwicklungsplattformen: n8n und Make arbeiten API-basiert und sind Middleware zwischen bestehenden Systemen — was das technisch bedeutet, erklärt unser Grundlagenartikel zur API-Integration in dieser Kategorie.

Wie unterscheiden sich Bedienung und Flexibilität?

Make ist auf geführte Bedienung optimiert. Der visuelle Editor mit seinen runden Modulen ist auf schnelle Erfolge ausgelegt: App auswählen, Konto verbinden, Felder zuordnen, fertig. Filter, Router und Iteratoren sind als fertige Bausteine vorhanden. Ein durchschnittlich digital-affiner Mensch aus dem Fachbereich baut nach kurzer Einarbeitung ein funktionierendes Szenario — das ist die eigentliche Stärke des Produkts.

n8n ist auf Kontrolle optimiert. Der Editor ist ebenfalls visuell, zeigt aber deutlich mehr vom Unterbau: Du siehst die durchlaufenden Daten als JSON, kannst Ausdrücke in fast jedes Feld schreiben und mit dem Code-Node eigenen JavaScript- oder Python-Code mitten im Workflow ausführen. Laut n8n-Dokumentation ist der Code-Node genau dafür da: Daten transformieren oder Logik ergänzen, die die eingebauten Nodes nicht abdecken. Wichtig fürs Kleingedruckte: Auf n8n Cloud kannst du keine externen npm-Module und keine Python-Bibliotheken importieren — volle Code-Freiheit inklusive Drittbibliotheken gibt es nur selbst gehostet.

In der Praxis heißt das: Die ersten 80 Prozent eines Standard-Workflows fühlen sich in beiden Tools ähnlich an. Der Unterschied zeigt sich bei den letzten 20 Prozent — verschachtelte Datenstrukturen, Sonderfälle, eigene Berechnungen, saubere Fehlerbehandlung. In Make baust du dafür teils umständliche Modul-Ketten; in n8n schreibst du zehn Zeilen Code. Umgekehrt gilt: Wer diese zehn Zeilen niemandem im Haus zutraut, hat mit n8n einen Werkzeugkasten gekauft, den keiner bedient.

Meine Einordnung: Die Frage ist weniger „Welches Tool ist einfacher?” als „Wer soll die Workflows in zwei Jahren pflegen?” Fachbereich ohne IT-Unterstützung → Make. Team mit mindestens einer technisch versierten Person → n8n zahlt sich mit jeder Sonderanforderung mehr aus.

Welche Integrationen gibt es?

Die nackten Zahlen, Stand Juli 2026: Make wirbt auf seiner Preisseite mit über 3.000 Apps in allen Plänen, das n8n-Integrationsverzeichnis listet 1.946 Integrationen.

Der Zahlenvergleich führt allerdings in die Irre, wenn du ihn zur Hauptentscheidung machst:

1. Beide decken den Business-Standard ab. CRM-Systeme, E-Mail, Kalender, Tabellen, Projektmanagement, Buchhaltung, Messaging, die gängigen KI-Modelle — die Werkzeuge, die in einem deutschen KMU typischerweise laufen, findest du in beiden Katalogen.
2. Der generische HTTP-Baustein schließt Lücken. Beide Tools können beliebige REST-APIs ansprechen, auch ohne fertigen Konnektor. Eine fehlende Integration ist damit selten ein K.-o.-Kriterium — sie kostet nur mehr Aufwand, weil du Authentifizierung und Datenformat selbst konfigurierst.
3. Qualität schlägt Quantität. Entscheidend ist, wie tief der Konnektor für deine Kernsysteme geht: Deckt er die Objekte und Aktionen ab, die du brauchst? Unterstützt er Webhooks, damit Ereignisse sofort statt per Abfrage-Intervall ankommen?

Praktische Empfehlung: Schreib deine fünf wichtigsten Systeme auf und prüfe für jedes in beiden Katalogen, ob die konkret benötigten Trigger und Aktionen existieren. Diese halbe Stunde ist mehr wert als jeder Katalogvergleich.

Wie funktionieren die Kostenmodelle?

Hier liegt der Unterschied, der langfristig am meisten Geld bewegt — nicht die Listenpreise, sondern die Abrechnungslogik.

Make rechnet pro Modulausführung ab. Die Einheit heißt Operation bzw. Credit; laut Make-Preisseite verbrauchen die meisten Aktionen 1 Credit, einige KI-Funktionen mehr. Entscheidend ist die Zähllogik aus der Make-Dokumentation: Module verarbeiten jedes Datenbündel einzeln — liefert ein Trigger 10 Datensätze, führt jedes nachfolgende Modul 10 Operationen aus. Datenmenge und Workflow-Länge multiplizieren sich also. Die Pläne (Stand Juli 2026, laut Preisseite, bei jährlicher Abrechnung): Free mit 1.000 Credits/Monat und maximal 2 aktiven Szenarien, Core ab 9 US-Dollar/Monat mit 10.000 Credits, Pro ab 16 US-Dollar, Teams ab 29 US-Dollar, Enterprise auf Anfrage. Der Free-Plan startet Szenarien frühestens alle 15 Minuten, bezahlte Pläne minütlich.

n8n rechnet pro Workflow-Lauf ab. Eine Execution ist laut Preisseite ein kompletter Durchlauf — egal ob der Workflow 3 oder 50 Schritte hat und ob er 1 oder 1.000 Datensätze verarbeitet. Die Cloud-Pläne (Stand Juli 2026, laut Preisseite): Starter ab 20 €/Monat mit 2.500 Executions, Pro ab 50 €/Monat mit 10.000 Executions, Business ab 667 €/Monat, Enterprise auf Anfrage — jeweils mit unbegrenzten Nutzern und Workflows. Dazu kommt die dritte Option, die Make nicht hat: die Community Edition selbst hosten, ohne nutzungsabhängige Lizenzkosten. „Kostenlos” ist das trotzdem nicht — Server, Einrichtung und laufende Pflege bezahlst du in Infrastruktur und Arbeitszeit (eine seriöse Gesamtkostenrechnung hängt so stark von deinem Setup ab, dass jede pauschale Zahl unseriös wäre).

Was das praktisch bedeutet: Ein täglicher Workflow, der 500 Datensätze durch 8 Schritte schiebt, kostet bei Make in der Größenordnung von 4.000 Operationen pro Lauf — bei n8n ist es genau 1 Execution. Umgekehrt: Viele kleine, kurze Szenarien mit wenigen Datensätzen bleiben bei Make günstig, und der Einstiegspreis liegt dort niedriger. Faustregel: Je datenintensiver und länger deine Workflows, desto stärker spricht die Abrechnungslogik für n8n.

Preise ändern sich — verlass dich nicht auf diesen Artikel, sondern rechne dein konkretes Mengengerüst auf den aktuellen Preisseiten beider Anbieter durch.

Was bietet Self-Hosting?

Das ist der kategorische Unterschied: Make gibt es ausschließlich als Cloud-Dienst. Deine Workflow-Daten laufen immer über Makes Infrastruktur. n8n kannst du vollständig selbst betreiben — laut Dokumentation per Docker (für Produktion empfohlen als Docker Compose mit eigener Datenbank), per npm oder auf gängigen Cloud-Plattformen. Selbst gehostete Installationen laufen standardmäßig als kostenlose Community Edition; Business- und Enterprise-Funktionen (etwa SSO, Umgebungen, Versionskontrolle) erfordern einen Lizenzschlüssel.

Self-Hosting bringt dir:

• Datenkontrolle: Kunden- und Prozessdaten verlassen deine Infrastruktur nicht über das Automatisierungstool. Für DSGVO-sensible Prozesse — Personaldaten, Gesundheitsdaten, Mandanteninformationen — ist das oft das ausschlaggebende Argument. (Details klärt der Geschwisterartikel zu n8n und DSGVO; grundsätzlich gilt: Self-Hosting allein macht nichts „automatisch konform”, es verschiebt nur die Verantwortung zu dir. Keine Rechtsberatung, Stand Juli 2026.)
• Kostenunabhängigkeit vom Volumen: Keine Execution-Limits, keine Nachkauf-Pakete bei Wachstum.
• Volle Code-Freiheit: Externe Bibliotheken im Code-Node sind laut n8n-Dokumentation nur selbst gehostet möglich.

Und es kostet dich:

• Betriebsverantwortung: Updates, Backups, Monitoring, Absicherung des Servers, Skalierung — all das liegt bei dir. Ohne eine Person, die das kann und dafür Zeit hat, wird die Ersparnis zur Hypothek.
• Kein Anbieter-Support in der Community Edition; du bist auf Community-Forum und eigene Kompetenz angewiesen.

Der Mittelweg für n8n ist die gehostete Cloud-Variante: Datenverarbeitung beim Anbieter wie bei Make, aber mit n8n-Funktionsumfang und späterer Migrationsoption auf eigene Infrastruktur. Die Detailabwägung dazu behandelt der Geschwisterartikel „n8n Cloud vs. Self-Hosted”.

Was passt zu komplexen Workflows?

„Komplex” heißt in der Praxis meist: viele Verzweigungen, Schleifen über große Datenmengen, eigene Geschäftslogik, saubere Fehlerbehandlung, mehrere beteiligte Systeme mit unterschiedlichen Datenformaten.

Hier sprechen drei Dinge für n8n:

1. Code als Ausweichoption. Jede Logik, die sich visuell nur umständlich abbilden lässt, wird ein Code-Node. Das hält Workflows kürzer und lesbarer, statt sie in Dutzende Hilfsmodule zu zerlegen.
2. Die Abrechnung bestraft Komplexität nicht. Ein 40-Schritte-Workflow über 2.000 Datensätze bleibt 1 Execution. In Make wächst mit jedem Schritt und jedem Datensatz der Credit-Verbrauch — das erzeugt einen ökonomischen Druck, Szenarien klein zu halten, der mit sauberer Architektur nichts zu tun hat.
3. Entwickler-Workflows. Selbst gehostet lässt sich n8n in bestehende IT-Praxis einbetten: Versionierung der Workflows, Test- und Produktionsumgebungen, eigene Bibliotheken. (Enterprise-Funktionen wie eingebaute Versionskontrolle und Umgebungen sind allerdings den Bezahl-Editionen vorbehalten.)

Fair bleibt: Make kann komplexe Szenarien ebenfalls abbilden — Router, Iteratoren, Aggregatoren und Fehler-Handler sind vorhanden, und für Teams ohne Entwickler ist ein komplexes Make-Szenario immer noch erreichbarer als ein komplexer n8n-Workflow mit Code-Nodes, den niemand versteht. Die ehrliche Frage ist auch hier die Wartbarkeit: Ein Workflow, den nur eine externe Agentur versteht, ist in beiden Tools ein Risiko.

Entscheidungsmatrix: n8n vs. Make nach Kriterien

Die Matrix fasst den Vergleich zusammen — bewusst nach Entscheidungskriterien statt nach Feature-Listen. „Vorteil” heißt: für ein typisches KMU-Szenario, nicht in jedem Einzelfall.

Kriterium	n8n	Make	Vorteil, wenn …
Einstieg & Bedienung im Fachbereich	Mehr Einarbeitung, technischeres UI	Stark geführt, schnelle erste Erfolge	Make, wenn Fachbereiche selbst bauen sollen
Flexibilität / eigene Logik	Code-Node (JavaScript/Python), Ausdrücke überall	Vorgefertigte Bausteine, kein freier Code	n8n, sobald Sonderlogik nötig ist
Integrationskatalog (Stand 07/2026)	1.946 Integrationen	3.000+ Apps	Unentschieden — beide decken Standard ab, HTTP-Baustein schließt Lücken
Abrechnungslogik	Pro Workflow-Lauf (Execution), schrittunabhängig	Pro Modulausführung (Credit), multipliziert mit Datenmenge	n8n bei langen, datenintensiven Workflows; Make bei vielen kleinen Szenarien
Einstiegskosten Cloud (Stand 07/2026)	Starter ab 20 €/Monat	Core ab 9 $/Monat, Free-Plan vorhanden	Make für den günstigen Start
Self-Hosting / Datenkontrolle	Community Edition auf eigener Infrastruktur	Nicht verfügbar (nur SaaS)	n8n, wenn Daten im Haus bleiben müssen
Betriebsaufwand	Selbst gehostet: liegt komplett bei dir	Null — verwalteter Dienst	Make (bzw. n8n Cloud), wenn niemand Server betreiben kann
Wartbarkeit komplexer Workflows	Code hält Workflows kompakt; IT-Praktiken möglich	Modul-Ketten wachsen mit Komplexität	n8n mit technischem Team
Kostenprognose bei Wachstum	Executions planbar, selbst gehostet volumenunabhängig	Credits wachsen mit Datenmenge und Schrittzahl	n8n bei steigendem Volumen

Kurzentscheidung in drei Fragen:

1. Müssen Prozessdaten auf eigener Infrastruktur bleiben? Ja → n8n (Self-Hosting), Make scheidet aus.
2. Gibt es im Team mindestens eine Person, die JSON liest und einfache Skripte schreibt oder lernen will? Nein → Make (oder n8n nur mit externem Partner für Aufbau und Wartung).
3. Sind deine Workflows eher lang und datenintensiv oder viele kleine Helfer? Lang und datenintensiv → n8n; viele kleine → Make bleibt günstig und pflegeleicht.

Umsetzung: So triffst du die Entscheidung belastbar

Statt Feature-Tabellen zu studieren, empfehle ich einen Pilotvergleich mit echtem Prozess — so gehe ich auch in Beratungsprojekten vor:

1. Einen echten, mittelschweren Prozess auswählen. Nicht den einfachsten (den kann jedes Tool) und nicht den härtesten. Typisch: Lead aus Webformular → CRM-Abgleich → Anreicherung → Benachrichtigung → Wiedervorlage.
2. Mengengerüst notieren. Wie oft läuft der Prozess pro Tag, wie viele Datensätze pro Lauf, wie viele Schritte? Damit rechnest du beide Preismodelle konkret durch — erst Zähllogik verstehen, dann Preisseite aufschlagen.
3. Beide Tools 2–4 Wochen parallel testen. Make im Free- oder Core-Plan, n8n als Cloud-Trial oder Docker-Testinstallation. Denselben Prozess in beiden bauen — auch als Test, wer im Team womit zurechtkommt.
4. Wartungsfall simulieren. Nach zwei Wochen eine Änderung einbauen lassen — von jemandem, der den Workflow nicht gebaut hat. Das Ergebnis sagt mehr über die richtige Wahl als jeder Katalogvergleich.
5. Betriebsfrage ehrlich beantworten. Bei n8n-Self-Hosting: Wer patcht, wer sichert, wer überwacht? Ohne Namen und Vertretung hinter diesen Aufgaben ist n8n Cloud oder Make die ehrlichere Wahl.

Wenn du dabei Unterstützung willst — von der Tool-Entscheidung bis zum ersten produktiven Workflow — schau dir unsere KI- und Automatisierungsberatung an oder buch ein unverbindliches Erstgespräch. Für Teams, die n8n selbst betreiben wollen, bieten wir außerdem Schulungen an.

Risiken & Grenzen

• Lock-in gibt es in beide Richtungen. Workflows sind nicht zwischen den Tools portierbar — ein späterer Wechsel heißt Neubau. Deshalb lieber vier Wochen sauber pilotieren als nach einem Jahr migrieren.
• Kostenüberraschungen bei Make entstehen fast immer durch die Multiplikation von Datenmenge und Schrittzahl, nicht durch den Listenpreis. Wer die Zähllogik (Bündel × Module) vor Vertragsabschluss nicht durchgerechnet hat, erlebt sie auf der Rechnung.
• Self-Hosting-Risiko bei n8n: Eine ungepflegte Instanz — keine Updates, keine Backups, offen im Netz — ist schlimmer als jede Cloud-Lösung. Self-Hosting ist ein Betriebsversprechen, kein Installationsereignis.
• Beide Tools ersetzen kein Prozessverständnis. Ein schlechter Prozess wird automatisiert nur schneller schlecht. Erst Prozess klären, dann Tool wählen.
• Zahlen und Preise veralten. Alle genannten Preise und Katalogzahlen sind Stand Juli 2026 von den verlinkten Anbieterseiten; Make hat sein Abrechnungsmodell in der Vergangenheit bereits umgestellt (von „Operations” auf „Credits”). Prüfe vor der Entscheidung die aktuellen Konditionen.

Checkliste: Deine Entscheidung in 10 Punkten

• Die fünf wichtigsten Systeme in beiden Integrationskatalogen geprüft (konkrete Trigger und Aktionen, nicht nur Logo vorhanden)
• Mengengerüst notiert: Läufe pro Tag, Datensätze pro Lauf, Schritte pro Workflow
• Beide Kostenmodelle mit dem eigenen Mengengerüst durchgerechnet (Make: Bündel × Module; n8n: Läufe)
• Geklärt, ob Prozessdaten das Haus verlassen dürfen — falls nein: n8n-Self-Hosting-Pfad prüfen
• Ehrlich beantwortet, wer im Team Workflows baut und wer sie in zwei Jahren wartet
• Bei Self-Hosting: Verantwortliche Person für Updates, Backups und Monitoring benannt (mit Vertretung)
• Denselben Pilotprozess in beiden Tools gebaut und den Aufwand verglichen
• Wartungstest gemacht: Eine fremde Person ändert den Workflow
• Exit-Szenario bedacht: Was kostet ein Neubau, wenn das Tool in drei Jahren nicht mehr passt?
• Aktuelle Preisseiten beider Anbieter am Entscheidungstag noch einmal geprüft

Fazit in einem Satz: Make gewinnt beim schnellen, günstigen Einstieg für Fachbereiche — n8n gewinnt, sobald Datenkontrolle, eigene Logik oder wachsendes Volumen ins Spiel kommen; und genau diese drei Faktoren solltest du prüfen, bevor du dich festlegst.