n8n-Kosten: Cloud vs. Self-Hosted und drei stille Fallen

Wer n8n einführt, vergleicht meist zwei Zahlen: die Monatsgebühr der Cloud und die Rechnung eines VPS. Beides greift zu kurz. Die tatsächlichen Kosten entstehen im Betrieb, und die teuersten Fehler zeigen sich nicht als Fehlermeldung, sondern als Workflow, der "grün" bleibt und trotzdem das Falsche tut. Der Text deckt beides ab: einen nüchternen Kostenvergleich und drei Stolperfallen aus dem Betrieb.

Die Preise stammen von den Anbietern, Stand Herbst 2026. Bitte vor einer Entscheidung aktuell prüfen. Zeit- und Stundensätze sind Rechenbeispiele, keine Marktdaten.

Kostenvergleich: Cloud vs. Self-Hosted

Die Cloud wirkt teurer, weil die Rechnung sichtbar ist. Beim Self-Hosting fehlt die Lizenzgebühr, aber es kommen Server, Backups, SSL, Monitoring, Updates und Fehlersuche hinzu. Werden diese Posten ehrlich eingerechnet, kippt der Vergleich bei kleinen Volumen zugunsten der Cloud.

Modell	Preis laut Anbieter	Was dazukommt
Cloud Starter	ab 20 EUR/Monat bei jährlicher Abrechnung (monatlich ca. 25 EUR), 2.500 Executions	Kontingent begrenzt, Verhalten bei Erreichen beim Anbieter prüfen
Cloud Pro	ab ca. 50 EUR/Monat bei jährlicher Abrechnung (monatlich ca. 60 EUR), 10.000 Executions	mehr Executions und parallele Ausführungen
Self-Hosted (VPS)	ca. 5 bis 15 EUR Server	Wartung, Updates, Backups, Monitoring
Enterprise	individuelles Angebot	SAML, SSO, Log-Streaming

Für die Wartung nennt der Kostenartikel je nach Szenario 2 bis 4 Stunden pro Monat bei ruhigem Betrieb und 10 bis 15 Stunden, wenn Updates, Backups, Monitoring und Bugfixing zusammenkommen. Als Beispiel für ungeplante Arbeit: Ändert sich eine API, kostet die Fehlersuche 2 bis 3 Stunden und die Anpassung 1 bis 2 weitere. Drei solcher Vorfälle im Monat ergeben 9 bis 15 Stunden.

Die Rechenbeispiele aus dem Kostenartikel im Bot-Agent Blog (jeweils mit 80 EUR Stundensatz gerechnet; Stundensatz und Cloud-Beträge sind grobe Annahmen, keine Anbieterpreise):

Szenario	Cloud	Self-Hosted
500 Executions/Monat	20 EUR	15 EUR Server + 2 Std. Wartung = ca. 175 EUR
15.000 Executions/Monat	ca. 100 EUR	40 EUR Server + 3 Std. Wartung = ca. 280 EUR
50.000+ Executions/Monat	250+ EUR	ca. 280 EUR, aber volle Kontrolle

Erst bei sehr hohem Volumen oder strengen Datenschutzanforderungen gleicht sich das an. Ohne eigenes DevOps-Wissen wird die Zeit zum eigentlichen Preis.

Ein Detail, das Listenpreise nicht zeigen: Das Execution-Kontingent ist begrenzt, und was bei Erreichen passiert, hängt vom Tarif ab. Nach aktuellen Angaben pausieren bei Starter und Pro die Workflows bis zum nächsten Abrechnungszeitraum, Overage-Pakete gibt es laut Preisseite für Business. Die Bedingungen sollten vor dem Kauf beim Anbieter geprüft werden. Ein vergessener Polling-Workflow kann das Monatskontingent allein durch häufiges Abfragen aufbrauchen. Beim Self-Hosting zählt stattdessen die Server-Kapazität.

Zur Einordnung der Abrechnungslogik: n8n zählt komplette Workflow-Durchläufe, Zapier einzelne Aktionen. Ein Workflow mit 50 Schritten ist bei n8n eine Execution. Bei Zapier zählt jede erfolgreich ausgeführte Aktion als Task (Trigger und eingebaute Tools wie Filter oder Formatter nicht), es wären also bis zu rund 49 Tasks.

Drei Fallen ohne Fehlermeldung

Der gefährlichste Fehlertyp ist dieser: Der Workflow läuft, aber Daten gehen verloren oder Entscheidungen fallen falsch. Es gibt keinen roten Node, keine Mail, nur falsche Ergebnisse. Aus dem Betrieb sind drei Muster typisch.

1. If-Node ohne combinator "and"

Bei einer If-Node, deren Bedingungs-JSON ohne combinator importiert oder per API angelegt wurde, haben wir beobachtet, dass immer der "true"-Zweig genommen wird (eigene Beobachtung, in der Doku nicht beschrieben). Das fällt nicht auf, weil die Ausführung erfolgreich endet. Beim Export eines Workflows lohnt ein Blick ins JSON:

{
  "conditions": {
    "combinator": "and",
    "conditions": [
      {
        "leftValue": "={{ $json.status }}",
        "operator": { "type": "string", "operation": "equals" },
        "rightValue": "dringend"
      }
    ]
  }
}

Fehlt "combinator": "and", sollte der Node geprüft werden, statt sich auf das grüne Häkchen zu verlassen. Gerade bei Filtern wie "nur dringende Anfragen benachrichtigen" ist das die Art Fehler, die Wochen unbemerkt bleibt.

2. process.env statt $env

In Code-Nodes ist process.env.NAME in der Sandbox (Task-Runner) nicht verfügbar. Der Zugriff auf Umgebungsvariablen läuft über $env. Seit n8n 2.0 ist der Zugriff darauf standardmäßig gesperrt (N8N_BLOCK_ENV_ACCESS_IN_NODE=true) und muss bewusst freigegeben werden, am besten gezielt per N8N_ENV_ACCESS_ALLOWLIST:

// funktioniert nicht in der Code-Node-Sandbox
const key = process.env.API_KEY;

// funktioniert, sofern der $env-Zugriff in der Instanz freigegeben ist
const key = $env.API_KEY;

Das Ergebnis ist kein Absturz, sondern ein leerer Wert, der später als fehlende Berechtigung oder leeres Feld auftaucht. Zugleich gilt: Geheimnisse gehören nicht hartcodiert in Nodes. Wo möglich, sind n8n-Credentials die bessere Wahl, Umgebungsvariablen eine Alternative.

3. executionOrder fehlt (v1)

In den Workflow-Einstellungen steuert executionOrder die Reihenfolge, in der Verzweigungen abgearbeitet werden. Die Einstellung legt fest, in welcher Reihenfolge Verzweigungen laufen: v1 arbeitet eine Verzweigung nach der anderen ab, das ältere v0 führt abwechselnd je Node jeder Verzweigung aus. Fehlt v1, haben wir in einem Fall erlebt, dass ein Node im Modus "Run Once for All Items" Items einer anderen Verzweigung erwischte:

{
  "settings": {
    "executionOrder": "v1"
  }
}

Auch hier gibt es keinen Fehler, sondern Daten aus dem falschen Zweig. Bei importierten oder älteren Workflows lohnt die Kontrolle dieser Einstellung.

Allen drei Fällen ist gemeinsam: Ein Testlauf mit einem Beispiel-Item zeigt grüne Häkchen. Geholfen haben ein Blick in die Execution-Historie (welche Nodes liefen, welche Daten flossen), Testdaten mit bewusst "falschen" Fällen und ein Error-Workflow, der Fehler meldet. Ein einfacher Error-Workflow ist meist schnell eingerichtet. Ein über zwei Wochen übersehener Fehler kann dagegen 10 bis 15 Stunden Handarbeit kosten. Auch ein abgelaufenes OAuth-Token (zum Beispiel bei Google Sheets) bricht Workflows still ab, wenn kein Error-Handler existiert. Die Einsteigerseite dazu steht im n8n Tutorial, unter anderem mit dem Hinweis, nach jedem externen Trigger einen Set-Node zur Normalisierung der Datenstruktur einzubauen.

Budgetkontrolle für LLM-Nodes

Kommen LLM-Nodes ins Spiel, wird aus "stiller Fehler" schnell "teurer stiller Fehler". Ein Polling-Workflow oder eine Schleife, die ein Modell pro Durchlauf aufruft, vervielfacht die Kosten, ohne dass n8n etwas meldet. Aus dem Betrieb folgen drei bewährte Regeln:

• Wenn möglich ein Limit beim LLM-Anbieter setzen (Tages- oder Monatslimit, je nach Anbieter), nicht erst in n8n. Ein hartes Limit beim Provider fängt auch Fehler im Workflow ab.
• Trigger prüfen: Jedes Polling-Intervall ist eine Execution, jede Execution kann einen Modellaufruf auslösen.
• Tests mit kleinen Datenmengen fahren. Ein Testlauf mit dem vollen Datensatz verbraucht echtes Budget.
• Einen Error-Workflow einrichten, der bei Abbruch oder Auffälligkeiten meldet, damit ein Fehler nicht zwei Wochen läuft.
• Eingaben vor dem LLM-Node validieren und leere oder kaputte Items gar nicht erst weiterreichen.

Fazit

Listenpreise sind der Anfang. Bei kleinen Volumen gewinnt die Cloud, Self-Hosting lohnt sich eher bei hohem Volumen, Admin-Wissen oder strikten Datenschutzanforderungen. Unabhängig vom Modell sind die teuersten Probleme die, die niemand sieht: ein If-Node ohne combinator, ein leeres process.env, eine fehlende executionOrder, ein vergessener Polling-Workflow. Wer Error-Handling und Budgetgrenzen von Anfang an einplant, spart mehr als mit jedem Hosting-Vergleich.

Hinweis: Dieser Beitrag ist Eigenwerbung (Werbung) des Anbieters von Bot-Agent. Ausführlicher mit Rechenbeispielen im Blog von Bot-Agent.