n8n, Make oder Zapier: was passt?

Make nimmt Ihnen den Betrieb komplett ab. Sie melden sich an, verbinden Ihre Konten und bauen los: kein Server, keine Updates, keine Backups, keine Verantwortung für Verfügbarkeit. Für Teams ohne IT-Ressourcen ist das kein Nebeneffekt, sondern das eigentliche Produkt.

n8n bietet beides: einen Cloud-Dienst und die Möglichkeit, die Plattform selbst zu betreiben. Self-hosted läuft n8n containerisiert auf Ihrer Infrastruktur oder in einem EU-Rechenzentrum, mit eigener Datenbank, Backups, verschlüsselten Zugangsdaten und getrennten Umgebungen für Test und Produktion. Der Preis dafür ist Betriebsverantwortung: Jemand muss Updates kontrolliert einspielen, statt sie über Nacht geschehen zu lassen.

Genau dieser Punkt kippt in der Praxis oft die Entscheidung, und zwar in beide Richtungen. Wer niemanden hat, der eine Instanz pflegt, ist mit SaaS besser bedient als mit einem Server, um den sich nach drei Monaten niemand mehr kümmert. Wer die Kontrolle braucht, gewinnt mit self-hosted mehr als nur ein Gefühl: Wenn eine Zusammenarbeit endet, läuft die Automatisierung unverändert weiter, weil Server, Instanz und Workflows Ihnen gehören.

Make rechnet nach Operations ab: grob gesagt zählt jeder Schritt in jedem Workflow-Durchlauf. Das ist im Einstieg günstig und angenehm transparent, solange die Zahl der Durchläufe klein bleibt. Die Rechnung dreht sich, wenn Volumen entsteht: Ein Workflow, der pro Vorgang zwölf Schritte durchläuft, kostet bei tausend Vorgängen im Monat das Zwölftausendfache eines einzelnen Schritts, und Vorgänge werden in wachsenden Unternehmen nun einmal mehr, nicht weniger.

Bei n8n self-hosted zahlen Sie Serverkosten, und die bleiben weitgehend gleich, egal wie oft ein Workflow läuft. Das ändert die Ökonomie grundlegend: Automatisierungen mit hoher Frequenz, Datenabgleiche im Minutentakt, Massenverarbeitung, Schleifen über große Listen, sind plötzlich kalkulierbar, statt einen Verbrauchszähler laufen zu lassen.

Rechnen Sie deshalb nicht die Einstiegspreise gegeneinander, sondern Ihr erwartetes Volumen in zwölf Monaten. Bei kleinen, seltenen Workflows gewinnt Make die Rechnung fast immer, weil die Einrichtung entfällt. Bei hohem oder wachsendem Volumen kippt sie zugunsten einer eigenen Instanz, und der Wechselzeitpunkt lässt sich vorher ausrechnen, statt ihn über eine unangenehme Rechnung zu erfahren.

Durch Automatisierungs-Workflows fließt selten Belangloses: Kundendaten aus dem CRM, Rechnungsdaten, Bewerbungen, teils Personaldaten. Bei einem SaaS-Dienst verlassen diese Daten Ihren Verantwortungsbereich und werden auf fremder Infrastruktur verarbeitet: zulässig, aber dokumentations- und vertragspflichtig, inklusive Auftragsverarbeitung und einer belastbaren Aussage darüber, wo die Verarbeitung stattfindet.

Self-hosted verschiebt diese Frage: Die Daten bleiben, wo sie ohnehin liegen, und die Datenflüsse sind vollständig dokumentierbar, weil sie über Ihre eigene Instanz laufen. Für Unternehmen mit strenger interner Compliance, für Gesundheits-, Finanz- und Personalprozesse oder für Betriebsräte, die genau hinschauen, ist das häufig der Punkt, der die Entscheidung allein trägt.

Machen Sie daraus trotzdem kein Dogma. Ein Workflow, der ausschließlich öffentliche Produktdaten in ein Dashboard schiebt, braucht keine eigene Infrastruktur. Die sinnvolle Frage lautet nicht „Cloud oder nicht?“, sondern: Welche Datenkategorien laufen durch welchen Workflow? In der Praxis führt das oft zu einer geteilten Landschaft, unkritisches im SaaS, sensibles auf eigener Instanz.

Make ist das zugänglichere Werkzeug. Die Oberfläche führt Sie durch die Verknüpfung, die fertigen Bausteine für gängige Dienste sind gut dokumentiert, und ein einfacher Ablauf steht in einer Stunde. Wer im Marketing oder Vertrieb sitzt und ohne IT loslegen will, kommt hier deutlich schneller zu einem Ergebnis.

n8n verlangt am Anfang mehr. Datenstrukturen sind sichtbarer, Ausdrücke ähneln eher Code als einer Formel, und wer nie mit APIs gearbeitet hat, braucht Anlauf. Dafür endet die Fahnenstange später: Wo Standard-Bausteine nicht reichen, schreiben Sie eigene Code-Schritte direkt im Workflow: HTTP-Aufrufe gegen beliebige Schnittstellen, eigene Transformationen, Verzweigungen, die sich mit Klickstrecken nicht abbilden lassen.

Das ist der eigentliche Wendepunkt in vielen Projekten. Solange Logik aus „wenn A, dann B“ besteht, tun sich beide Werkzeuge wenig. Sobald Ausnahmen, Sonderfälle und Datenverrenkungen dazukommen, und in echten Geschäftsprozessen kommen sie immer dazu, , wird die Klickoberfläche zur Fessel, während der Code-Schritt das Problem in drei Zeilen löst.

Beide Plattformen können Fehler behandeln: beide werden dabei standardmäßig zu wenig genutzt. Ein Workflow, der still scheitert, wenn ein System nicht antwortet, ist gefährlicher als Handarbeit: Es merkt nur niemand, und zwei Wochen später fällt auf, dass Rechnungen nicht durchgelaufen sind. Das ist keine Werkzeugfrage, sondern eine Handwerksfrage.

Der Unterschied liegt in der Tiefe. Make bietet solide Bordmittel für Wiederholungsversuche und Fehlerpfade, bindet Sie aber an das, was die Plattform vorsieht. Auf einer eigenen n8n-Instanz definieren Sie zusätzlich eigene Fehler-Workflows, hängen Benachrichtigungen an Ihre Kanäle, greifen auf vollständige Ausführungsprotokolle zu und binden das Ganze an Ihr bestehendes Monitoring an, statt in ein zweites Dashboard zu schauen.

Unabhängig vom Werkzeug gilt derselbe Maßstab: Ein Workflow ist erst produktiv, wenn klar ist, was bei Störung passiert, nicht, wenn er einmal erfolgreich durchgelaufen ist. Dazu gehören Wiederholungslogik bei temporären Ausfällen, benannte Ansprechpartner für Benachrichtigungen, ein dokumentierter manueller Notfallpfad und eine Dokumentation, die auch jemand versteht, der den Workflow nicht gebaut hat.

Erstens: kleines Volumen, Standard-Tools, keine sensiblen Daten. Wer Formular-Einträge in eine Tabelle schreibt und eine Benachrichtigung verschickt, braucht keine eigene Instanz. Der Betriebsaufwand wäre teurer als der Nutzen. Zweitens: kein Betrieb möglich. Wenn niemand im Unternehmen eine Instanz pflegen kann und Sie das auch nicht auslagern wollen, ist SaaS die ehrlichere Wahl als ein Server ohne Kümmerer.

Drittens: schnelle Validierung. Bevor Sie in eine Automatisierungslandschaft investieren, ist ein Prototyp in Make oft der günstigste Weg herauszufinden, ob ein Prozess überhaupt so funktioniert, wie alle glauben. Und viertens: Wenn Ihr Team bereits produktiv mit Make arbeitet, ist ein Komplettumbau selten sinnvoll. Migriert werden die Workflows, bei denen es sich rechnet, nicht alle, weil ein neues Werkzeug im Haus ist.

Unsere eigene Praxis ist deshalb hybrid: Standard-Werkzeuge, wo sie reichen, n8n und eigener Code, wo Volumen, Datenschutz oder Komplexität es verlangen. Entscheidend ist am Ende nicht die Plattform, sondern dass jeder Workflow dokumentiert, überwacht und übergabefähig ist: daran scheitern Projekte, nicht an der Werkzeugwahl.

Bevor Sie sich für ein Werkzeug entscheiden, klären Sie den Prozess: Welche Abläufe kosten wöchentlich am meisten Zeit, wie oft laufen sie, welche Daten fließen durch sie hindurch? Diese drei Angaben entscheiden die Werkzeugfrage fast von selbst, und sie verhindern den häufigsten Fehler, nämlich einen Umweg mit zu automatisieren, statt ihn abzuschaffen. Wie wir Abläufe aufnehmen und priorisieren, lesen Sie unter Prozessautomatisierung; wie wir n8n betreiben, unter n8n-Agentur. Wo KI als Schritt im Workflow wirklich Sinn ergibt, zeigt der Ratgeber KI im Mittelstand. Erste Workflows starten bei uns ab 5.000 €, und die Ersparnis rechnet sich typischerweise in 3–6 Monaten: im Erstgespräch sagen wir Ihnen auch, wenn ein Prozess die Automatisierung schlicht nicht wert ist.