Zapier vs Make vs n8n (2026): Preise, echte Kosten und was in Produktion bricht

Zuletzt getestet: Juli 2026

Jede Automatisierungsplattform zählt Nutzung anders, und das ist kein Zufall. Zapier rechnet pro Task, Make.com pro Operation, n8n pro Execution. Diese drei Wörter sehen auf einer Pricing-Seite austauschbar aus. Sind sie nicht. Derselbe Workflow kann 208 $ auf Zapier, 20 $ auf Make oder den Preis eines VPS auf selbst gehostetem n8n kosten.

Dieser Leitfaden ist ein Praktiker-Walkthrough, wie jede Plattform zählt, wo die versteckten Kosten lauern und welche Plattform bei welcher Volumen-Band tatsächlich gewinnt. Ich fahre produktive Workflows auf Make und n8n für eigene Produkte (Teedian, eine Content-Operations-Engine), also spiegeln die Beispiele reale Verdrahtung wider, keine Marketing-Mathematik.

Das kurze Fazit: unter 500 Läufen pro Monat funktioniert fast jedes Free-Tier. Zwischen 500 und 5.000 Läufen pro Monat ist Make.com Core der Sweet Spot. Oberhalb 5.000 gewinnt selbst gehostetes n8n fast immer, wenn Sie die Ops-Kapazität haben. Zapier gewinnt selten bei Kosten oberhalb des Starter-Tiers — ist aber häufig der schnellste Weg, etwas zu shippen.

Warum Preisvergleiche schwer sind

Drei Gründe, warum Preisvergleiche zwischen Automatisierungsplattformen fast immer in die Irre führen.

Erstens: die Einheiten sind verschieden. Ein Zapier-Task ist ein Aktionsschritt. Eine Make-Operation ist eine Modul-Ausführung. Eine n8n-Execution ist ein vollständiger Workflow-Lauf. Dieselbe Logik auf allen drei zählt Zapier viermal, Make sechsmal, n8n einmal.

Zweitens: Loops, Filter und Error-Handler zählen auf jeder Plattform anders. Make zählt jede Iteration innerhalb eines Loops und Branches innerhalb eines Error-Handlers. Zapier zählt Pfade als separate Multi-Step-Features. n8n interessiert sich nicht, wie viele Nodes Sie haben — nur wie oft der Workflow lief.

Drittens: Retries und Polling blähen Rechnungen still auf. Wenn ein Lauf scheitert und dreimal retryt, sind das 3× Nutzung auf Zapier und Make, und 3× Execution-Count auf n8n Cloud. Polling-Trigger, bei denen die Plattform alle paar Minuten eine API checkt, können eine Quota sprengen, bevor überhaupt Arbeit passiert.

Sie können keine Listenpreise vergleichen. Sie müssen denselben Workflow, beim gleichen realistischen Volumen, mit Retries und Fehlerpfaden vergleichen.

Zapier: Tasks erklärt

Zapier rechnet pro Task. Ein Task ist jeder erfolgreiche Aktionsschritt in einem Zap. Der Trigger zählt nicht. Jeder folgende Schritt schon.

Ein 5-Schritt-Zap, der 100-mal pro Monat feuert, verbraucht 400 Tasks — der Trigger ist frei, die vier Aktionsschritte zählen je einmal pro Lauf. Ein 10-Schritt-Zap bei 100 Fires verbraucht 900 Tasks. Paths, Filter und Iteration-Features multiplizieren das weiter.

Aktuelles Zapier-Pricing, 2026:

Der Sprung von Professional zu Company ist 25× das Task-Allotment, aber nur 2,8× der Preis — die Per-Task-Kosten fallen deutlich, wenn Sie tatsächlich alle 50.000 nutzen. Die meisten Company-Tier-Käufer zahlen für Compliance, nicht Volumen.

Wo Zapier schnell teuer wird, ist Mittelvolumen-Arbeit. Bei 10.000 Tasks pro Monat sind Sie schon außerhalb von Professional und zahlen für Company-Kapazität, die Sie nicht voll nutzen. Der klassische Migrations-Triggerpunkt.

Make.com: Operationen erklärt

Make.com rechnet pro Operation. Eine Operation ist eine einzelne Modul-Ausführung in einem Scenario. Jedes Modul, das läuft, zählt eine Operation — inklusive innerhalb von Iteratoren. Router und Filter selbst zählen nicht, aber Module innerhalb schon.

Derselbe 5-Schritt-Zapier-Workflow, nach Make portiert, landet üblicherweise bei 5 bis 7 Operationen pro Lauf, weil Make oft ein Extra-Modul für Datenmanipulation braucht, das Zapier in seinen Aktionsschritt bündelt.

Make.com-Pricing, 2026:

Makes Vorteil: Core bei 10,59 $ gibt 10× die Operationen für 1/3 des Preises von Zapier Starter. Der größte Einzel-Grund, warum Teams von Zapier abwandern.

Die Falle bei Make: Iteration und Error-Handling. Einen Iterator über ein 50-Item-Array triggert 50 Operationen pro nachgelagertem Modul. “Incomplete Executions”, der Retry-Mechanismus für gescheiterte Scenarios, verbraucht bei jedem Retry Operationen. Error-Handler-Branches mit eigenen Modulen zählen auch.

Budgetieren Sie 1,1× bis 1,2× Ihres gemessenen Volumens für Retries und Fehlerpfade. Wenn Ihre Scenarios in einem sauberen Monat 8.000 Operationen laufen, planen Sie 9.500 in einem echten Monat.

n8n: Executions erklärt

n8n rechnet pro Execution auf Cloud. Eine Execution ist ein vollständiger Workflow-Lauf — egal wie viele Nodes er hat. Ein 3-Node-Workflow und ein 30-Node-Workflow zählen beide als 1 Execution pro Trigger.

Das ist ein fundamental anderes Modell. Bei Zapier und Make kosten zusätzliche Schritte Geld. Bei n8n sind zusätzliche Nodes frei. Sie bezahlen nur, wie oft der Workflow feuert.

n8n-Cloud-Pricing, 2026:

Selbst gehostetes n8n ist der Ausreißer. Ein 20-€-Hetzner-VPS fährt unbegrenzte Workflows und unbegrenzte Executions. Der Haken: Sie betreiben es. Backups, Upgrades, SSL, Monitoring, Incident-Response werden alle Ihr Problem. Diese Ops-Kosten sind real — und der Hauptgrund, warum Teams trotz der Unit-Ökonomie des Self-Hostings auf n8n Cloud bleiben.

Wenn Sie schon Linux-Services produktiv betreiben, zahlt sich selbst gehostetes n8n binnen eines Monats bei jedem nennenswerten Volumen zurück. Wenn nicht, schlägt n8n Cloud Pro bei 50 € für 10.000 Executions Zapier und Make in den meisten Volumen-Bändern.

Vollständiges Setup im n8n-Self-Hosting-Leitfaden.

Weitere Plattformen kurz

Drei Plattformen tauchen häufig in RFPs auf und verdienen Erwähnung.

Zoho Flow rechnet pro Flow-Run, bei dem ein Trigger einem Lauf entspricht. Modell nah an n8ns Execution-Modell. Preise liegen zwischen Zapier und Make bei ähnlichen Volumina; die Plattform ist stärkst innerhalb des Zoho-Ecosystems (CRM, Desk, Books). Außerhalb haben Make und n8n reichere Connector-Bibliotheken.

IFTTT rechnet pro Applet-Run. Ein Trigger-Fire ist ein Lauf. IFTTT ist konsumentenorientiert, Pro-Tier ist günstig, aber die Connector-Palette für B2B-Services hinkt den drei Großen hinterher. Nützlich für Home-Automation und Social-Posting, selten passend für operative Business-Workflows.

Microsoft Power Automate rechnet pro Flow-Run in Premium-Tiers, mit Lower-Tier-Plänen inside Microsoft 365. Pricing ist enterprise-fokussiert und ohne Quote opaque. Das Killer-Feature: enge Microsoft-365- und Dynamics-Integration. Wenn Ihr Stack Microsoft-first ist, ist Power Automate der Default, und die Kostendiskussion dreht sich um Seats und Premium-Connectors, nicht Per-Run-Volumen.

Seite an Seite bei realistischem Volumen

Drei übliche Volumen-Bänder mit echten Zahlen, saubere Monat + Standard-Retry-Raten angenommen.

Kleines Team, 500 Läufe pro Monat, 3 Schritte pro Lauf (1.500 Zapier-Task-Äquivalent):

Sieger: Make. Zapier ist 7× die Kosten für dieselbe Arbeit.

Mittleres Team, 5.000 Läufe pro Monat, 5 Schritte pro Lauf (25.000 Zapier-Tasks):

Sieger: n8n selbst gehostet, wenn Sie Ops-Skills haben, Make wenn nicht. Zapier Company macht hier finanziell keinen Sinn, außer Sie brauchen Compliance-Features.

Großes Team, 50.000 Läufe pro Monat, 8 Schritte pro Lauf (400.000 Zapier-Tasks):

Sieger: n8n selbst gehostet mit Ops-Owner, oder Make Enterprise für Vendor-gemanagte Infrastruktur mit vertrautem Builder.

Versteckte Kosten, die die meisten übersehen

Fünf Kostenleaks, die auf keiner Pricing-Seite stehen.

Fehler-Retries. Zapier und Make zählen Retry-Läufe als neue Tasks oder Operationen. Ein Workflow, der eine flatternde Downstream-API trifft und dreimal retryt, kostet 4× die Happy-Path-Nutzung. 1,1× bis 1,2× für Retries in jedes Volumen-Estimate einrechnen.

Iteration innerhalb eines Schritts. Ein 20-Item-Array in Make durchzuloopen triggert 20 Operationen pro Modul im Loop. Dieselbe Iteration in einem Zapier-Multi-Step-Zap nutzt Zapiers bezahltes Looping-Feature, das als Zusatz-Tasks abgerechnet wird. Ein 20-Item-Loop mit 3 Modulen innen sind 60 Operationen in Make. Summiert sich bei täglich laufenden Scenarios schnell.

Webhook-Flooding. Ein Upstream-Service, der 10 Webhooks pro Sekunde für eine Minute feuert, sind 600 Trigger. Wenn Ihr Workflow jeden verarbeitet, sind das 600 Läufe. Am Filter rate-limiten oder ein Queue-Modul zum Debouncen davor setzen, bevor die echte Logik läuft.

Error-Handler-Branches. In Make zählen Module innerhalb eines Error-Handler-Routes als Operationen. Teams fügen oft großzügiges Error-Handling hinzu, das die Operation-Anzahl pro Scenario still verdoppelt. Fehlerpfade schlank halten — zu einem externen Service loggen statt fünf Make-Module für eine Mail-Formatierung einzubauen.

Geplantes Polling. Ein Polling-Trigger alle 5 Minuten sind 8.640 Trigger-Fires pro Monat — bevor überhaupt ein Aktionsschritt läuft. Wo möglich Webhook-Trigger oder Push-basierte APIs nutzen. Polling ist die größte stille Kostenquelle auf Make und Zapier.

Derselbe Workflow, drei Plattformen, echte Zahlen

Ein konkretes Beispiel, das ständig hochkommt: Shopify-Order-Processing mit Klaviyo-Enrichment.

Die Logik: Neuer Shopify-Order feuert den Trigger, Kunden von Klaviyo holen, nach VIP-Status branchen. Wenn VIP: Airtable-Record anlegen und Slack-Alert senden. Wenn nicht: nur Airtable-Record.

Bei 1.000 Orders pro Monat:

Derselbe Workflow, dasselbe Volumen, 13× Preisdifferenz zwischen den Extremen. Die Wahl zwischen Make und n8n hier ist Präferenz. Make hat die bessere UI für Business-User. n8n hat die besseren Primitiven für Engineers, die ihre Automatisierung in Git versionieren wollen.

Für einen vollen Builder-Vergleich siehe die Produktions-Abschnitte weiter unten und den DACH-Walkthrough Make vs. n8n Vergleich.

Migrations-Taktiken, wenn das Pricing reißt

Drei Migrationspfade decken die meisten realen Fälle ab.

Zapier zu Make ist der häufigste erste Schritt. Typische Ersparnis bei 1.000+ Tasks pro Monat: 60 bis 80 Prozent. Die Workflows portieren recht sauber, weil beide visuelle Builder mit ähnlichen Modul-Konzepten sind. Planen Sie zwei bis drei Tage Re-Wiring pro signifikantem Zap, weniger bei unter zehn Workflows. Voller Walkthrough: Zapier zu Make migrieren.

Make zu n8n selbst gehostet ist der zweite Sprung. Ersparnisse bei 10.000+ Operationen pro Monat: 80 bis 95 Prozent direkte Plattformkosten, gegengerechnet mit VPS und Ops-Zeit. Richtiger Move, wenn Sie Linux produktiv fahren und JSON-definierte Workflows unter Git haben wollen.

Zapier direkt zu n8n ist der größte mentale Shift. Wechsel von reinem visuellen SaaS zu einem Builder, der Code zugänglich macht, auf Ihrer Infrastruktur läuft (wenn Sie wollen) und sehr anders zählt. Ersparnisse sind riesig, aber die Lernkurve steiler. Step-by-Step: Zapier zu n8n migrieren.

Pricing-agnostische Empfehlungen:

1. Mit der Plattform starten, die Ihren Use Case im Free- oder niedrigsten Paid-Tier abdeckt
2. Läufe und Schritte monatlich messen, nicht quartalsweise
3. Migration planen, wenn Sie 2× die Free- oder Starter-Tier-Nutzung erreichen
4. At Scale ist selbst gehostetes n8n fast immer die niedrigste Plattform-Kostenposition — aber Ops-Zeit ist ein echter Posten

Wann Enterprise-Pricing sich lohnt

Enterprise-Tiers sind nicht für Volumen gepreist. Sie sind für Compliance, Support und Planbarkeit gepreist.

Vier Signale, dass Enterprise-Tier die richtige Wahl ist — unabhängig von der Kostenrechnung:

• Audit-Log- oder SOC2-Anforderung. Wenn Ihr Compliance-Team einen Audit-Trail braucht, wer wann welche Automatisierung geändert hat, sind Enterprise-Tiers der sauberste Weg.
• SLA-gestützte Uptime. Wenn ein Automatisierungs-Failure echten Umsatz kostet (Payments, Order-Fulfillment, Trading-Signale), ist ein vertraglich geregeltes SLA den Aufpreis wert.
• Dedizierter Support. Wenn ein Kern-Workflow um 3 Uhr morgens kaputtgeht, zählt ein Support-Kontakt, der Ihren Account kennt, mehr als der Unit-Preis.
• Volumen-Commit für Planbarkeit. Finance bevorzugt oft ein flaches Jahres-Commit gegenüber variabler Per-Run-Abrechnung — selbst wenn die variable Option in den meisten Monaten günstiger wäre.

Wenn keines dieser Signale zutrifft, ist der Enterprise-Tier meist Überausgabe. Auf Core oder Pro bauen, wenn möglich selbst hosten, und Compliance kaufen, wenn Compliance tatsächlich das ist, was Sie brauchen.

Entscheidungs-Framework nach Volumen

Eine Spickzettel für den 90-%-Fall:

Zwei Querschnitte zur Tabelle:

• Wenn Sie die absolut schnellste Time-to-First-Working-Zap wollen und unter 2.000 Tasks pro Monat sind, gewinnt Zapier bei Geschwindigkeit, auch wenn es bei Unit-Kosten verliert.
• Wenn Sie einen Engineer haben, der bereits Linux-Services produktiv betreibt, ist selbst gehostetes n8n der Default ab 2.500+ Läufen pro Monat.

Automatisierungs-Pricing hört auf verwirrend zu wirken, sobald Sie aufhören, Listenpreise zu vergleichen, und anfangen, Ihren tatsächlichen Workflow bei Ihrem tatsächlichen Volumen zu vergleichen. Schritte zählen, Retries zählen, Polling zählen — und die richtige Plattform wird offensichtlich.

Was in Produktion zuerst bricht

Pricing sagt Ihnen, welche Plattform am günstigsten ist. Produktion zeigt, welche standhält. Ich betreibe sowohl Make.com als auch n8n produktiv für Kunden. Content-Pipelines, Datenanreicherungs-Flows, CRM-Sync-Jobs, KI-Agent-Orchestrierung. Einige davon laufen mit tausenden Executions pro Woche. Hier ist, was wirklich zählt, sobald man die Tutorial-Phase hinter sich hat.

Die Kurzfassung: Make.com ist eine Managed-Plattform mit Pro-Operation-Pricing, robuster Webhook-Queue und visuellem Debugging. Gut für lineare Workflows. n8n ist selbst gehostete Infrastruktur mit unbegrenzten Executions ab etwa 20 € Server-Kosten, voller Datenresidenz und stärkerer KI-Agent-Orchestrierung. Wahl nach Ownership, Volumen und Compliance, nicht nach Featureliste.

Der Kernunterschied dahinter: Make.com ist eine Managed-Plattform. n8n ist Infrastruktur, die Sie besitzen. Klingt offensichtlich, aber die Implikationen treffen Sie nachts um 2, wenn etwas kaputtgeht. Bei Make.com kümmert sich deren Team um Uptime, Skalierung und Security-Patches. Bei n8n ist das Ihr Job oder der des Kunden. Das ist kein Qualitätsurteil. Es ist eine Architektur-Entscheidung. Und sie sollte die erste sein, die Sie treffen — nicht die letzte.

Wenn Sie das für ein Team entscheiden und nicht für einen einzelnen Workflow, denken Sie es als Make-or-Buy. Make.com ist Buy: planbare Kosten pro Seat und pro Operation, keine Ops-Last, Daten auf deren Servern. n8n self-hosted ist Make: nahezu keine Grenzkosten bei Volumen, volle Datenresidenz in Ihrer VPC und eine Betriebsverantwortung, die jemand tragen muss. Der Break-Even ist selten der Listenpreis, sondern ob Sie die Ops-Kapazität haben, n8n zuverlässig zu betreiben. Für regulierte oder EU-Datenresidenz-Fälle zeigt der Leitfaden Generative KI für Unternehmen in DACH, wo Self-Hosting nicht verhandelbar wird.

Wo Make.com standhält: Webhooks, Debugging, Error-Handling

Webhook-Zuverlässigkeit. Make.coms Webhook-Infrastruktur ist battle-tested. Webhooks queuen automatisch, wenn ein Szenario pausiert oder rate-limited ist. Ich habe Make.com-Webhook-Queues gesehen, die tausende Events während einer Downstream-API-Downtime gehalten und nach Resume sauber abgearbeitet haben. n8n-Webhooks hängen an Ihrer Instanz. Wenn der n8n-Server fällt, sind diese Webhooks weg. Sie müssen eine eigene Queue-Schicht bauen (Redis, Message Broker oder ein Reverse-Proxy mit Retry-Logik), um dieselbe Zuverlässigkeit zu bekommen.

Visuelles Debugging bei Skalierung. Wenn ein Szenario in Schritt 14 von 23 scheitert, zeigt Make.com die exakten Daten an jedem Schritt. Man klickt durch die Execution-Historie, sieht, was rein und raus ging und wo es brach. Für Kunden, die ihre Workflows selbst debuggen müssen, ist das schwer zu replizieren. n8n hat Execution-Logs, aber die Debug-Erfahrung für komplexe Multi-Branch-Workflows ist rauer. Man verbringt mehr Zeit in Logs und weniger in der visuellen Inspektion.

Error-Handling-Patterns. Make.coms Error-Handler-Routen (break, resume, ignore, rollback) sind ein First-Class-Feature. Man hängt einen Error-Handler an jedes Modul und definiert exakt, was passieren soll. Das ist in Produktion enorm wichtig, weil jeder API-Call fehlschlagen kann — und der Workflow das elegant abfangen muss. n8n hat try/catch über den Error-Trigger-Node, aber auf Workflow-Ebene, nicht Node-Ebene. Feingranulare Fehlerbehandlung braucht mehr Verdrahtung.

Wo n8n standhält: Code, Datenresidenz, Versionskontrolle

Code, wenn nötig. n8n erlaubt an jedem Node den Sprung in JavaScript (oder Python). Wenn der visuelle Builder nicht reicht, schreiben Sie einen Function-Node — weiter geht’s. Make.com hat kein Pendant. Sie sind auf das limitiert, was deren Module anbieten. Für Custom-Logik rufen Sie eine externe API oder einen Webhook zu einem separaten Service auf. Das fügt Latenz, Komplexität und einen weiteren Fehlerpunkt hinzu.

Daten bleiben auf Ihrer Infrastruktur. Selbst gehostetes n8n bedeutet: Ihre Daten verlassen Ihre Infrastruktur nicht. Für Kunden in Healthcare, Finance oder DSGVO-sensitiven Bereichen kann das harte Anforderung statt Präferenz sein. Make.com verarbeitet Daten auf eigenen Servern. SOC-2-konform, EU-Hosting-Optionen existieren — aber für manche Compliance-Frameworks ist “unsere Daten bleiben auf unseren Servern” die einzig akzeptable Antwort. Der n8n-Self-Hosting-Leitfaden geht das VPS-Setup, den Reverse-Proxy und die Backup-Strategie durch, die ich bei DACH-Kunden nutze.

Git-basierte Versionskontrolle. n8n-Workflows sind JSON-Dateien. Sie können sie in git committen, Diffs sehen, zurückrollen, in einem PR reviewen. So arbeiten Software-Teams. Make.com-Blueprints lassen sich als JSON exportieren, aber der Round-Trip ist nicht sauber. Das JSON ist geschwätzig, IDs ändern sich beim Import, und eine eingebaute Versionskontrolle gibt es nicht. In der Praxis landet man bei “Szenario Kopie (3)” statt bei einem richtigen Changelog.

Make.com vs. n8n für KI-Workflows

Beide Plattformen unterstützen inzwischen KI-Agent-Workflows. Hier verbringe ich die meiste Kundenzeit, also die ehrliche Einordnung.

Make.com + KI: Funktioniert gut für lineare KI-Pipelines. Input rein, LLM verarbeitet, Output raus. Das HTTP-Modul ruft jede API. Aber Multi-Step-Agent-Verhalten (bei dem der nächste Schritt vom KI-Output abhängt) in einem visuellen Builder zu orchestrieren, wird schnell unbequem.

n8n + KI: Die LangChain-Nodes und der AI-Agent-Node liefern nativere Agent-Patterns. Tool Use, Memory, Chain-of-Thought-Routing. Wenn Ihr Workflow lautet “KI entscheidet den nächsten Schritt”, fühlt sich n8n natürlicher an.

Keine der beiden Plattformen ist super für komplexe Agent-Orchestrierung. Irgendwann brauchen Sie Code. Aber für KI-gestützte Workflows (nicht vollautonome Agenten) funktionieren beide.

Produktions-Checkliste: welche Plattform Ihren Workload übersteht

Das benutze ich mit jedem Kunden:

Make.com wählen, wenn:

• Das Team nicht-technisch ist und Workflows selbst warten muss
• Webhook-Zuverlässigkeit kritisch ist und Sie keine Infrastruktur betreiben wollen
• Der Workflow primär API-zu-API-Datenbewegung ist
• Sie produktives Error-Handling ohne Custom-Code brauchen

n8n (selbst gehostet) wählen, wenn:

• Kosten bei Skalierung zählen (hoher Durchsatz)
• Sie Custom-Code im Workflow brauchen
• Daten auf eigener Infrastruktur bleiben müssen
• Sie git-basierte Versionskontrolle und CI/CD für Ihre Automatisierungen wollen
• Das Team Engineering-Kapazität hat, um Infrastruktur zu betreiben

Keines von beiden wählen, wenn:

• Der Workflow komplex genug ist, eine richtige Codebase zu rechtfertigen
• Sub-Sekunden-Latenz gefragt ist
• Die Automatisierung zum Kernprodukt gehört, nicht zum unterstützenden Prozess

Der letzte Punkt ist wichtig. Sowohl Make.com als auch n8n sind exzellent für operative Automatisierung. Sie sind keine Application-Backends. Wenn Kunden mich bitten, ihre Produktkernlogik in Make.com zu bauen, lege ich Veto ein.

Ein Schlusspunkt aus dem Betrieb beider Plattformen: Die Plattform zählt weniger als die Architektur. Ich habe gut gebaute Make.com-Setups schlampig aufgesetzte n8n-Deployments schlagen sehen — und umgekehrt. Was zählt: Error-Handling an jedem Schritt, idempotente Operationen, Monitoring und Alerting, saubere Trennung zwischen Workflows — und zu wissen, wann man aus dem visuellen Builder aussteigt und Code schreibt.

Changelog

• 2026-07-11: Make-vs-n8n-Produktions-Guide in diese Seite integriert; Abschnitte zu Produktions-Zuverlässigkeit ergänzt.