Inngest: Event-driven Workflows für TypeScript und Python mit Durable Execution

Was ist Inngest?

Inngest ist eine Plattform für event-driven Workflows mit durable execution, 2021 von Tony Holdstock-Brown und Dan Farrelly in San Francisco gegründet. Die Position im Markt ist konkret: Inngest zielt auf Developer-Teams, die in TypeScript oder Python arbeiten und Workflows als Code direkt in der Anwendung halten wollen – ohne separates Workflow-Server-Setup wie bei Temporal oder Airflow.

Das Konzept funktioniert in drei Schichten. Erste Schicht: SDK in der Anwendung (TypeScript, Python). Funktionen werden mit Decorator/Wrapper als „Inngest Function" markiert, ihre Schritte mit step.run, step.sleep, step.waitForEvent strukturiert. Zweite Schicht: Inngest-Cloud oder Self-Host (der Inngest-Server ist Apache 2.0 unter Open-Source-Lizenz). Der Server triggert Funktionen über Events, verwaltet State und garantiert Retry. Dritte Schicht: das Event-Modell. Statt direkt Workflows zu starten, sendet die Anwendung Events („user.signed_up", „payment.received", „invoice.generated"); der Inngest-Server entscheidet, welche Funktionen darauf reagieren.

Stand Mai 2026 sind die SDKs in TypeScript, Python, Go, Kotlin, sowie experimentell in Java und Rust verfügbar. Die Funktionalität ist in TypeScript am ausgereiftesten – viele Beispiele und Patterns kommen aus dem Next.js- und Node.js-Ökosystem.

Kommerziell hat Inngest zwei Pfade. Erstens: Inngest Cloud – Free mit 50.000 Function-Runs/Monat, Hobby mit USD 0/Monat für kleinere Setups, Pro ab USD 50/Monat für 250.000 Runs plus Konkurrenz-Features, Enterprise auf Anfrage. Zweitens: Self-Hosted – der Inngest-Server ist seit 2024 Apache 2.0 auf GitHub. Self-Host ist eine valide Option für Teams, die Daten zwingend in EU/CH halten müssen.

Die Cloud läuft primär auf US-AWS-Regionen, eine dedizierte EU-Region ist nicht standardmässig vorgesehen. Wer Inngest unter EU-Recht braucht, wechselt zu Self-Host.

Warum es wichtig ist

Inngest löst ein Problem, das speziell für TypeScript-Engineering-Teams relevant ist: durable execution mit Sleep und Wait-for-Event direkt in der Anwendung, ohne separates Workflow-Server-Cluster. Wer eine Next.js- oder Express-Anwendung baut und Workflows wie „User signs up -> Welcome-Mail -> 24h später Onboarding-Tipp -> 7 Tage später Re-Engagement" abbilden will, kann das in Inngest in 30 Zeilen TypeScript ausdrücken.

Der Vergleich mit Temporal ist instruktiv. Temporal ist mächtiger und sprachlich diverser (7 SDKs), aber das Setup ist komplexer (mehrere Server-Komponenten, eigene Worker-Prozesse). Inngest ist auf das Minimal-Setup optimiert: die Workflows leben in der existierenden Anwendung, der Server kommt als Cloud oder als einzelner Docker-Container. Für Teams in der „Mid-Range" zwischen einfachem Workflow (n8n) und mission-critical Distributed (Temporal) ist Inngest die richtige Wahl.

Für eine CH-Treuhand sind realistische Hebel begrenzter als bei n8n, aber konkret. Erstens – Onboarding-Workflows für SaaS-Produkte. Wenn eine Treuhand-Plattform eine eigene SaaS-Lösung anbietet (Self-Service-Buchhaltung, Mandanten-Portal), sind Inngest-Funktionen die idiomatische Wahl für User-Lifecycle-Logik. Welcome-Mail nach Signup, Trial-Ablauf nach 14 Tagen, Re-Engagement nach Inaktivität.

Zweitens – Background-Jobs in einer Web-Anwendung. Wer eine Express- oder Next.js-Anwendung baut, hat oft Background-Jobs (PDF generieren, Mails versenden, externe API-Calls mit Retry). In Inngest sind diese Jobs als reguläre Funktionen mit Sleep und Retry-Logik formuliert – kein separates BullMQ- oder Sidekiq-Setup nötig.

Drittens – Webhook-Verarbeitung. Stripe, HubSpot, GitHub und andere SaaS-Anbieter senden Webhooks. Wer diese zuverlässig verarbeiten will (Retry bei Failure, Deduplizierung, idempotente Verarbeitung), kann Inngest als Webhook-Receiver nutzen. Der Inngest-Server übernimmt die Persistierung, die Anwendung übernimmt die Geschäftslogik.

Die Kehrseite: Cloud-Hosting in den USA, Self-Host noch jünger als bei n8n oder Activepieces, kleinere Community. Wer Self-Host braucht, sollte zuerst prüfen, ob der Setup-Aufwand zum Funktions-Gewinn passt.

Wie es funktioniert

Ein Inngest-System besteht aus zwei Teilen: dem SDK in der Anwendung und dem Inngest-Server (Cloud oder Self-Host). Im Code definiert man Funktionen, die auf Events reagieren. Eine Funktion hat einen Namen, einen Event-Trigger und eine async-Funktion mit der Logik. Die Logik wird in „Steps" gegliedert – step.run, step.sleep, step.waitForEvent.

Ein typisches Beispiel in TypeScript: `inngest.createFunction({ id: "onboard-user" }, { event: "user/signed_up" }, async ({ event, step }) => { await step.run("send-welcome", () => sendWelcomeMail(event.data.email)); await step.sleep("wait-24h", "24h"); await step.run("send-tip", () => sendOnboardingTip(event.data.email)); });`. Beim Trigger eines "user/signed_up"-Events startet der Inngest-Server die Funktion. Step 1 (Welcome-Mail) wird ausgeführt. Dann wartet der Server 24 Stunden, persistiert den Zustand, und ruft die Funktion danach wieder auf – dieses Mal mit dem Step-1-Ergebnis aus der History, sodass Step 2 (Tip-Mail) ausgeführt wird.

Die Steps sind das durable-execution-Modell. Wenn der Server zwischen Step 1 und Step 2 abstuerzt, wird er nach Restart die Funktion replayed – Step 1 wird aus der History geliefert (nicht erneut ausgeführt), Step 2 wird neu gestartet. Idempotenz wird durch Step-IDs garantiert, sofern Steps idempotent geschrieben sind.

Events sind die zentrale Trigger-Quelle. Statt direkt Funktionen aufzurufen, sendet die Anwendung Events: `await inngest.send({ name: "user/signed_up", data: { email: "..." } })`. Der Server entscheidet anhand der registrierten Funktionen, welche Funktionen das Event verarbeiten. Mehrere Funktionen können das gleiche Event verarbeiten, eine Funktion kann mehrere Events verarbeiten.

Die Architektur unterstützt drei Trigger-Typen: Events (asynchron, mit fan-out), Cron-Schedules (zeitbasiert), und Scheduled Functions (delayed). Plus die step.waitForEvent-Funktion, die im Workflow auf ein externes Event wartet – für Approval-Flows oder Multi-Step-Prozesse.

Das SDK kommuniziert mit dem Server via HTTP. Bei Self-Host ist der Server ein Docker-Container, der über den Webhook-URL der Anwendung erreichbar sein muss. Bei Cloud-Hosting läuft das alles im Hintergrund. Die Latenz zwischen Event und Funktionsstart liegt typisch bei 100-500 Millisekunden.

Die Konkurrenz-Steuerung („concurrency limits") ist eine spezielle Stärke: pro Funktion oder pro Event-Schlüssel lässt sich definieren, wie viele Instanzen parallel laufen dürfen. Damit wird Backpressure auf externe APIs vermieden – z.B. „max 5 parallele Stripe-Calls pro Sekunde".

Inngest in 5 Schritten integrieren

1. 01Inngest-Account anlegen (Cloud Free für Start) oder Self-Host-Server als Docker-Container deployen (Apache 2.0 auf GitHub).
2. 02SDK in der Anwendung installieren (npm install inngest oder pip install inngest), Client-Initialisierung in einer Konfigurationsdatei.
3. 03Webhook-Endpoint exposen: Next.js api/inngest oder Express-Route, der Inngest-Handler registriert alle Funktionen.
4. 04Erste Funktion schreiben: createFunction mit Event-Trigger, async-Logic mit step.run und step.sleep, lokal mit npx inngest-cli dev testen.
5. 05Monitoring aktivieren: Inngest Cloud Dashboard für Function-Runs, Slack/Mail-Alerts bei Failure-Rate > 1%, Concurrency-Limits für externe API-Calls setzen.

Wann Inngest einsetzen

Inngest ist die richtige Wahl, wenn (a) das Team TypeScript oder Python schreibt, (b) Workflows als Code direkt in einer existierenden Anwendung gehalten werden sollen, (c) durable execution mit Sleep und Wait-for-Event gebraucht wird und (d) der Setup-Aufwand minimal bleiben soll.

Konkrete Fälle: User-Lifecycle-Workflows in SaaS-Produkten (Onboarding, Trial-Ablauf, Re-Engagement, Churn-Rückholung), Background-Jobs in Web-Anwendungen mit Retry-Logik (PDF-Generierung, Mail-Versand, externe API-Calls), zuverlässige Webhook-Verarbeitung (Stripe, HubSpot, GitHub), Multi-Step-Prozesse mit User-Approval (Bestellgenehmigung, Mandanten-Onboarding mit GwG-Prüfung), zeitbasierte Workflows mit Sleep (z.B. „in 7 Tagen Erinnerung senden").

Für Engineering-Teams in mittleren KMU oder Treuhand-Plattformen, die TypeScript-Backend-Stacks haben (Next.js, Express, Hono), ist Inngest die idiomatische Wahl. Die Lernkurve ist niedrig (eine Funktion mit step.run in 30 Minuten geschrieben), die Cloud-Variante kostet die ersten 50k Runs nichts.

Für Self-Host in EU/CH ist Inngest seit 2024 eine valide Option. Der Server läuft als einzelner Docker-Container, das Setup dauert 30 Minuten. Im Vergleich zu Temporal (mehrere Server-Komponenten plus Datenbank) ist Inngest deutlich einfacher zu betreiben.

Für Standard-RAG- und Agent-Workflows ist Inngest mit den Custom-LangChain-Anbindungen in TypeScript oder Python gut geeignet. Eine RAG-Pipeline kann als Inngest-Funktion mit step.run-Schritten implementiert werden – Embedding, Vector-Store-Search, LLM-Call.

Wann NICHT

Inngest ist die falsche Wahl für No-Code-Teams. Es gibt zwar eine Cloud-UI für Function-Monitoring, aber keine Drag-and-Drop-Editor. Marketing- oder Sales-Teams ohne Engineering-Resource können Inngest nicht selbst betreiben – n8n, Make, Activepieces oder Zapier sind die richtige Wahl.

Ungeeignet ist Inngest für reine Drag-and-Drop-SaaS-Verknüpfungen ohne Code. Wer „Slack-Nachricht bei neuem HubSpot-Deal" baut, hat in Zapier oder Make 5 Minuten Setup, in Inngest braucht es einen Code-Stack (Node.js oder Python) und ein Server-Deployment.

Nicht passend ist Inngest, wenn der Anwendungsfall klar im Data-Engineering-Bereich liegt (ELT, Data-Warehouse, ML-Training). Airflow oder Dagster sind dort produktiver – Inngest ist auf transaktionale Workflows in Anwendungen optimiert, nicht auf Daten-Pipelines.

Für sehr breite Konnektor-Anforderungen (Hunderte SaaS-Apps verbinden) ist Inngest nicht das richtige Tool. Es gibt keine vordefinierten Konnektoren – jede Integration läuft als regulärer Code-Call in der Anwendung. n8n mit 600+ Nodes oder Make mit 1.500+ Apps sind dort schneller.

Für IoT/IIoT-Anwendungen ist Inngest ungeeignet – keine MQTT-, Modbus-, oder OPC-UA-Unterstützung. Node-RED ist dort die richtige Wahl.

Für sehr hohe Stückzahlen mit Real-Time-Anforderungen (Millionen Events/Sekunde) ist Inngest nicht optimiert. Die Plattform liegt im Bereich Tausende Events/Sekunde komfortabel; für mehr braucht es Kafka, Apache Flink oder dedizierte Streaming-Plattformen.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Inngest documentation – functions, steps, events · 2026-05
2. Inngest pricing page · 2026-05
3. Inngest on GitHub – Apache 2.0 server and SDKs · 2026-05
4. Inngest durable execution and step model · 2026-04