Der Fachbegriff für das Konzept, das Inngest umsetzt, lautet „durable functions“ – zu Deutsch etwa „dauerhafte“ oder „widerstandsfähige Funktionen“. Gemeint ist ein Ausführungsmodell, bei dem eine Funktion nicht in einem Rutsch durchlaufen muss, sondern in einzelne Schritte zerfällt, deren Zwischenergebnisse dauerhaft gespeichert werden. Fällt ein Schritt aus – weil ein fremder Dienst gerade nicht antwortet oder ein Server neu startet –, wird nur dieser Schritt automatisch wiederholt, während die bereits erledigten Schritte nicht erneut ausgeführt werden. Ein Ablauf kann so Minuten, Stunden oder sogar Tage dauern, ohne dass ein Prozess durchgängig laufen muss.
Damit fällt Inngest in eine andere Kategorie als klassische No-Code-Automatisierung. Es geht nicht darum, per Klick zwei Apps zu verbinden, sondern darum, technischen Teams ein zuverlässiges Fundament für ihren eigenen Code zu geben. Wer bisher einen Auftrag in eine Warteschlange geschoben, einen Arbeiter-Prozess dafür betrieben und die Fehlerbehandlung selbst gebaut hat, bekommt bei Inngest all das als verwalteten Dienst – gesteuert durch Events (Ereignisse), die Funktionen auslösen.
Aus unserer Projektpraxis lässt sich die Zielgruppe klar umreißen. Inngest richtet sich an Entwicklungsteams, die eigene Software betreiben und darin zuverlässige Hintergrundabläufe brauchen: Auftragsverarbeitung, Benachrichtigungen, Datenabgleiche, mehrstufige Prozesse mit Wartezeiten oder rechenintensive Aufgaben, die nicht im Sekundentakt einer Web-Anfrage erledigt werden können. Überall dort, wo bislang eine eigene Warteschlange plus Arbeiter-Prozesse aufgesetzt worden wäre, ist Inngest eine naheliegende Alternative.
Weniger geeignet ist Inngest für reine Fachabteilungen ohne Softwareentwicklung, die zwei fertige Apps ohne eine Zeile Code verknüpfen möchten. Für solche Aufgaben sind klassische No-Code-Werkzeuge zugänglicher. Inngest ist bewusst ein Entwicklerwerkzeug – es setzt voraus, dass im Team Code geschrieben, getestet und verantwortet wird. Als reines Cloud-Angebot ist es zudem dort kritisch zu prüfen, wo aus Datenschutz- und Souveränitätsgründen eine vollständige Kontrolle über die Ausführung verlangt wird – ein Punkt, den wir in Kapitel 09 vertiefen.
Der Kern der Sache lässt sich an einem typischen Entwickleralltag festmachen. In fast jeder Anwendung gibt es Aufgaben, die nicht sofort im Rahmen einer Nutzeranfrage erledigt werden sollten: eine Rechnung erzeugen und versenden, ein Video umwandeln, mehrere fremde Schnittstellen nacheinander aufrufen, nach drei Tagen eine Erinnerung schicken. Klassisch löst man das mit einer Warteschlange, Arbeiter-Prozessen und selbst gebauter Wiederholungslogik – ein spürbarer Betriebsaufwand, der leicht fehleranfällig wird, sobald ein Dienst zwischendurch ausfällt.
Durable functions drehen diese Logik um: Man schreibt den Ablauf als zusammenhängende Funktion, markiert die einzelnen belastbaren Abschnitte als Schritte und überlässt Inngest die Ausführung. Fällt der dritte von fünf Schritten aus, setzt die Plattform genau dort wieder an, statt den ganzen Ablauf von vorn zu beginnen. Das verschiebt die Grenze dessen, was ohne eigenes Infrastruktur-Projekt zuverlässig machbar ist, deutlich nach oben. Gleichzeitig verlangt es dieselbe Disziplin wie jeder Code: Die Abläufe müssen verstanden, getestet und gewartet werden. Inngest nimmt Teams also nicht die Denkarbeit ab, sondern befreit sie von einem großen Teil der wiederkehrenden Infrastruktur-Arbeit.
Im Zentrum steht ein einfaches Modell: Events (Ereignisse) werden an Inngest gesendet; Functions (Funktionen) reagieren darauf; jede Funktion besteht aus Steps (Schritten), deren Zustand die Plattform verwaltet. Der eigene Code läuft dabei in der eigenen Umgebung, während Inngest als Orchestrierungs- und Zustands-Schicht darüber sitzt. Um diesen Kern herum haben sich die SDKs für mehrere Sprachen, ein lokaler Entwicklungs-Server und das gehostete Cloud-Angebot gruppiert.
Inngest besetzt eine Nische zwischen zwei Welten. Auf der einen Seite stehen die klassischen Bausteine der Softwareentwicklung: eine Nachrichten-Warteschlange, dazu selbst betriebene Arbeiter-Prozesse und eigene Wiederholungslogik – mächtig, aber betriebsaufwendig und fehleranfällig. Auf der anderen Seite stehen schwergewichtige Workflow-Engines wie Temporal, die sehr viel können, aber auch einen entsprechenden Einarbeitungs- und Betriebsaufwand mit sich bringen. Inngest positioniert sich dazwischen: die Zuverlässigkeit einer Workflow-Engine, aber mit dem Anspruch, sich schnell und mit wenig Zeremonie in bestehende Anwendungen einbinden zu lassen.
Diese Positionierung erklärt die typische Nutzergruppe: Produkt- und Entwicklungsteams, die eine moderne Anwendung betreiben und darin zuverlässige Hintergrundabläufe brauchen, ohne dafür ein eigenes Infrastruktur-Team abzustellen. Für sie ist der ereignisgesteuerte Ansatz vertraut, und der Wegfall der selbst gebauten Warteschlange ein echter Gewinn. Inngest tritt damit nicht gegen No-Code-Werkzeuge wie Zapier oder Make an, sondern gegen die Eigenbau-Infrastruktur und gegen andere Entwicklerplattformen für zuverlässige Abläufe.
Ein wichtiger Punkt der Einordnung ist das zweigeteilte Betriebsmodell. Im Zentrum steht das gehostete Cloud-Angebot, das Orchestrierung, Zustandsverwaltung, Wiederholungen und Überwachung übernimmt. Bemerkenswert ist dabei ein Detail: Der eigene Code läuft nicht auf der Infrastruktur von Inngest, sondern in der eigenen Umgebung – Inngest ruft ihn über einen Endpunkt auf und steuert die Ausführung. Ergänzt wird das durch einen lokalen Dev-Server, mit dem sich Funktionen ohne Cloud-Verbindung auf dem eigenen Rechner entwickeln und testen lassen. Zentrale Bestandteile der Plattform sind quelloffen. Für Unternehmen mit strengen Souveränitätsanforderungen ist diese Aufteilung zentral – wir kommen darauf in Kapitel 06 und 09 zurück.
Jede Inngest-Funktion folgt demselben Grundmuster: Sie ist an einen Auslöser gebunden – ein Event oder einen Zeitplan – und besteht innen aus einer Folge von Schritten. Ein Schritt ruft etwa eine fremde Schnittstelle auf, schreibt in eine Datenbank oder versendet eine Nachricht. Entscheidend ist, dass das Ergebnis jedes Schritts festgehalten wird: Der nächste Schritt kann darauf zugreifen, und im Fehlerfall setzt der Ablauf genau am unterbrochenen Schritt wieder an. So entsteht ein nachvollziehbarer Verlauf vom auslösenden Event bis zum letzten Schritt, der sich bei jedem Durchlauf einzeln überprüfen lässt.
Ein typisches Beispiel aus dem E-Commerce: Ein Event „Bestellung eingegangen“ löst eine Funktion aus. Schritt eins reserviert den Bestand, Schritt zwei erzeugt die Rechnung, Schritt drei ruft den Zahlungsdienst auf, Schritt vier versendet die Bestätigung. Fällt der Zahlungsdienst im dritten Schritt kurz aus, wiederholt Inngest nur diesen Schritt automatisch – Bestand und Rechnung sind längst erledigt und werden nicht doppelt verarbeitet. Was bei einer selbst gebauten Warteschlange sorgfältige Idempotenz- und Fehlerlogik erfordert, ist hier eingebautes Verhalten.
Der wichtigste Baustein verdient eine genauere Betrachtung. Ein Schritt ist im Kern ein abgegrenztes Stück Arbeit, dessen Ergebnis dauerhaft gemerkt wird. Genau diese Persistenz macht die automatischen Wiederholungen sicher: Weil erledigte Schritte nicht erneut ausgeführt werden, führt ein zweiter Versuch nicht zu doppelten Rechnungen oder doppeltem Versand. Diese Eigenschaft – Idempotenz auf Schrittebene – ist der stille Held zuverlässiger Abläufe und in Eigenbau-Lösungen die häufigste Fehlerquelle.
Damit deckt Inngest einen Bereich ab, der bei klassischer Warteschlangen-Infrastruktur nur mit erheblichem Aufwand erreichbar ist. Der Preis dafür ist eine gewisse Umstellung im Denken: Man muss lernen, Abläufe in sinnvolle Schritte zu zerlegen, und beachten, dass der Code zwischen den Schritten mehrfach durchlaufen werden kann. Wir empfehlen in Projekten, Schritte bewusst klar zu schneiden – jeder Schritt eine überschaubare, wiederholbare Einheit – und die eigentliche Wirkung (Datenbankschreiben, Versand) immer innerhalb eines Schritts zu kapseln, nie dazwischen.
Über die reine Zuverlässigkeit hinaus bietet Inngest Werkzeuge, um die Ausführung zu steuern. Flow Control begrenzt die Gleichzeitigkeit, drosselt die Rate und priorisiert – wichtig, um eine angebundene Schnittstelle oder die eigene Datenbank nicht zu überlasten, wenn plötzlich viele Events eintreffen. Scheduling erlaubt geplante Läufe per Zeitplan sowie gezieltes Pausieren über lange Zeiträume, etwa „warte drei Tage, dann sende eine Erinnerung“. Und Fan-out verteilt Arbeit: Ein einziges Event kann viele Funktionen auslösen, und ein Ablauf kann Aufgaben parallel auf viele Läufe verteilen. Wir prüfen in Projekten immer, welche dieser Steuermechanismen ein Ablauf wirklich braucht – gerade die Begrenzung der Gleichzeitigkeit wird häufig unterschätzt und verhindert später teure Überlast-Zwischenfälle.
Die KI-relevanten Fähigkeiten von Inngest lassen sich grob in drei Bereiche gliedern: die zuverlässige Orchestrierung von Aufrufen an Sprachmodelle, die Steuerung mehrstufiger Agenten-Abläufe mit Wartezeiten und Freigaben sowie die verlässliche Ausführung langlaufender Hintergrund-Jobs rund um KI. Allen gemeinsam ist, dass Inngest nicht selbst das Sprachmodell stellt, sondern den Rahmen bietet, in dem KI-Aufrufe robust, wiederholbar und nachvollziehbar ablaufen.
KI-Agenten arbeiten typischerweise in mehreren Runden: Das Modell überlegt, ruft ein Werkzeug auf, verarbeitet dessen Ergebnis, überlegt erneut. Solche Abläufe sind mit klassischer Anfrage-Antwort-Logik schwer verlässlich abzubilden – sie dauern zu lange, können an jeder Stelle scheitern und müssen ihren Zustand über viele Schritte halten. Genau hier passt das Schritt-Modell von Inngest: Jeder Modell-Aufruf und jeder Werkzeug-Aufruf wird zu einem eigenen Schritt, dessen Ergebnis gespeichert und der bei einem Fehler gezielt wiederholt wird. So bleibt ein Agenten-Ablauf auch dann beherrschbar, wenn ein einzelner Modell-Aufruf einmal fehlschlägt oder eine fremde Schnittstelle zeitweise nicht antwortet.
Ein weiterer Vorteil: Weil eine Funktion mitten im Ablauf auf ein Event warten kann, lassen sich Freigabeschritte mit menschlicher Beteiligung sauber einbauen. Ein Agent bereitet etwa einen Vorschlag vor, der Ablauf pausiert, ein Mensch bestätigt per Klick, und erst dann läuft der Agent weiter. Diese Kombination aus Autonomie und kontrollierten Haltepunkten ist aus unserer Sicht der verantwortungsvollste Weg, KI-Agenten in produktive Prozesse zu bringen.
Viele KI-Aufgaben sind rechen- und zeitintensiv: ein großes Dokument abschnittsweise zusammenfassen, viele Datensätze klassifizieren, Einbettungen für eine Suche erzeugen. Solche Jobs passen nicht in das enge Zeitfenster einer Web-Anfrage und würden eine eigene Hintergrund-Infrastruktur erfordern. Mit Inngest wird daraus eine ereignisgesteuerte Funktion, die die Arbeit in Schritte zerlegt, per Fan-out parallelisiert und per Flow Control so drosselt, dass weder das Sprachmodell-Kontingent noch die eigene Datenbank überlastet wird. Der Fortschritt bleibt erhalten, auch wenn der Job Stunden dauert – ein deutlicher Gewinn gegenüber fragilen Eigenbau-Lösungen.
In der Praxis empfehlen wir einen nüchternen Blick: Inngest macht KI-Abläufe zuverlässig, aber es macht sie nicht automatisch sinnvoll. Der Mehrwert entsteht dort, wo eine Aufgabe echtes Sprach- oder Kontextverständnis erfordert und zugleich langlaufend oder mehrstufig ist – etwa die schrittweise Verarbeitung großer Textmengen oder ein Agent, der mehrere Systeme koordiniert. Für einfache, kurze KI-Aufrufe ohne Zuverlässigkeitsanspruch ist der Aufwand einer durable function dagegen oft überzogen; hier genügt ein direkter Aufruf.
Wir prüfen in Projekten daher bei jedem geplanten KI-Ablauf zwei Fragen: Erstens, ob die Aufgabe wirklich Verständnis erfordert oder ob eine simple Regel genügt. Zweitens, ob der Ablauf lang, mehrstufig oder fehleranfällig genug ist, dass sich die Zuverlässigkeit von Inngest auszahlt. Gerade agentische Ansätze verführen dazu, mehr Autonomie zuzulassen, als ein Prozess verträgt – die eingebauten Haltepunkte für menschliche Freigaben sollten hier großzügig genutzt werden.
Auf der ersten Ebene stehen die SDKs für TypeScript/JavaScript, Python und Go. Mit ihnen definiert man Funktionen und sendet Events – direkt aus der eigenen Anwendung heraus, in der gewohnten Sprache. Damit fügt sich Inngest in vorhandene Projekte ein, statt eine separate Welt zu bilden. Weil der eigene Code in der eigenen Umgebung läuft, kann er auf alles zugreifen, was das jeweilige Sprach-Ökosystem bietet: Bibliotheken, Datenbank-Zugriffe, interne Dienste.
Die zweite Ebene ist die Einbindung über Web-Frameworks. Inngest bindet sich in der Regel über einen einzelnen HTTP-Endpunkt in eine bestehende Anwendung ein – die Plattform ruft die Funktionen über diesen Endpunkt auf. Dadurch lässt sich Inngest zu vielen verbreiteten Frameworks und Hosting-Umgebungen hinzufügen, ohne die Architektur umzubauen. Für Teams bedeutet das konkret: Man behält seinen bestehenden Technologie-Stack und ergänzt lediglich die zuverlässige Ausführungs-Schicht. Diese Nähe zum vorhandenen Code ist der Hauptgrund, warum Entwicklungsteams Inngest gegenüber einer eigenen Warteschlangen-Infrastruktur bevorzugen.
Die dritte Ebene ist das Event-Modell. Alles beginnt mit einem Ereignis: Eine Anwendung, ein Webhook oder ein anderer Dienst sendet ein Event an Inngest, das daraufhin die passenden Funktionen startet. Weil ein einzelnes Event mehrere Funktionen auslösen kann, entkoppelt dieses Modell die Auslöser von den Reaktionen – eine bewährte Architektur-Idee. Ein Team kann so neue Reaktionen auf ein bestehendes Ereignis ergänzen, ohne die auslösende Stelle anzufassen. Auch externe Systeme lassen sich über Webhooks anbinden, deren Nutzlast als Event in Inngest ankommt und dort einen zuverlässigen Ablauf startet.
Für den Betrieb entscheidend ist die eingebaute Beobachtbarkeit. Inngest zeigt für jeden Funktionslauf, welche Schritte ausgeführt wurden, welche Daten sie erhalten und welches Ergebnis sie erzeugt haben, wo Wiederholungen nötig waren und wo ein Ablauf gerade wartet. Diese Nachvollziehbarkeit ist einer der unterschätzten Vorteile: Fehlersuche in verteilten Hintergrundabläufen ist notorisch schwierig, und ein lückenloser Verlauf pro Lauf erspart viel Rätselraten. Ergänzt wird das durch die Möglichkeit, Inngest programmatisch anzusprechen und in eigene Entwicklungs- und Auslieferungsprozesse einzubinden – Funktionen werden versioniert und wie normaler Code behandelt.
Der wichtigste Unterschied lässt sich in einem Satz fassen: Eine klassische Warteschlange gibt Ihnen Bausteine, Inngest gibt Ihnen ein fertiges Ausführungsmodell. Mit einer Nachrichten-Warteschlange und selbst betriebenen Arbeiter-Prozessen haben Sie maximale Kontrolle, müssen aber Wiederholungen, Idempotenz, Zustandsverwaltung, Zeitpläne und Überwachung selbst bauen und betreiben – ein erheblicher, dauerhafter Aufwand, der in der Praxis oft unterschätzt wird. Inngest nimmt Ihnen diesen Unterbau ab: Zuverlässigkeit, Wiederaufnahme und Beobachtbarkeit sind eingebaut, und Sie konzentrieren sich auf die eigentliche Logik. Der Preis ist eine Abhängigkeit von der Plattform und deren Betriebsmodell.
Am nächsten stehen Inngest zwei Werkzeuge. Temporal verfolgt eine sehr ähnliche Grundidee der dauerhaften Ausführung, ist aber mächtiger, sprachlich breiter und zugleich schwergewichtiger – es richtet sich eher an Organisationen, die komplexe, geschäftskritische Orchestrierung im großen Maßstab betreiben und den höheren Einarbeitungs- und Betriebsaufwand in Kauf nehmen. Temporal lässt sich zudem vollständig selbst hosten, was für Souveränitätsanforderungen ein starkes Argument ist. Trigger.dev steht Inngest konzeptionell am nächsten: ebenfalls durable functions, ebenfalls ereignisgesteuert, mit einem starken Fokus auf das TypeScript-Ökosystem. Die Wahl zwischen den beiden hängt oft von Sprach-Vorlieben, konkreten Funktionsdetails und dem gewünschten Betriebsmodell ab.
In unseren Projekten formulieren wir die Faustregel gern so: Klassische Queue für maximale Kontrolle und vorhandenes Infrastruktur-Team, Inngest für schnelle, zuverlässige Abläufe ohne eigenen Unterbau, Trigger.dev als naher TypeScript-fokussierter Verwandter, Temporal für schwergewichtige Orchestrierung mit Selbst-Hosting-Option. Nicht selten ist die beste Lösung eine bewusste Kombination – etwa eine bestehende Warteschlange für einfache Aufgaben und Inngest für die mehrstufigen, langlaufenden Abläufe, bei denen sich die eingebaute Zuverlässigkeit auszahlt.
Der große Vorteil des Modells ist der schnelle Start bei geringem Infrastruktur-Aufwand. Ein Team bindet das SDK in seine bestehende Anwendung ein, definiert erste Funktionen, testet sie lokal mit dem Dev-Server und verbindet sich dann mit der Cloud, die Orchestrierung, Wiederholungen und Überwachung übernimmt. Für Teams, die sich auf ihre Anwendungslogik konzentrieren wollen und nicht auf den Betrieb einer eigenen Queue, ist das ein echter Gewinn – man erhält Zuverlässigkeit, ohne die Last eigener Hintergrund-Infrastruktur.
Aus unserer Projektpraxis hat sich ein schrittweises Vorgehen bewährt, das den entwicklungsnahen Charakter der Plattform berücksichtigt und trotzdem beherrschbar bleibt.
Nach dem Start verschiebt sich der Fokus vom Bauen auf das Betreiben. Zentrale Themen sind die Beobachtung der Funktionsläufe, das saubere Behandeln von Fehlern und das Feinjustieren der Steuermechanismen. Weil Inngest jeden Lauf mit allen Schritten detailliert protokolliert, ist die Fehlersuche vergleichsweise komfortabel – man sieht genau, welcher Schritt welche Daten erhalten, wo eine Wiederholung nötig war und wo ein Ablauf gerade wartet. Diese Nachvollziehbarkeit ist einer der unterschätzten Vorteile der Plattform.
Gleichzeitig gilt: Auch eine gemanagte Plattform enthebt niemanden der Verantwortung für die eigene Logik. Ein Schritt, der eine externe Schnittstelle aufruft, muss mit deren Ausfall umgehen können; die Grenzen für Gleichzeitigkeit müssen zu den angebundenen Systemen passen. Wir empfehlen, für geschäftskritische Abläufe von Beginn an festzulegen, wer im Fehlerfall verantwortlich ist und wie schnell reagiert werden muss – und die Wiederholungsgrenzen so zu wählen, dass ein dauerhaft fehlschlagender Schritt nicht endlos Kosten verursacht.
Auffällig ist ein Muster: Inngest glänzt dort, wo Zuverlässigkeit über Zeit gefragt ist – Abläufe, die mehrstufig sind, warten müssen, fehlschlagen können oder lange dauern. Sobald eine Aufgabe über den einfachen Rahmen einer Web-Anfrage hinausgeht und verlässlich zu Ende gebracht werden muss, spielt die Plattform ihre Stärke aus. Der Mehrwert entsteht weniger durch Bedienkomfort als durch die eingebaute Widerstandsfähigkeit gegen Fehler und Unterbrechungen, die anderswo mühsam selbst gebaut werden müsste.
Wichtig für die Erwartungshaltung: Der Nutzen realisiert sich nur, wenn im Team eigene Software entwickelt wird. Ein schlecht durchdachter Prozess wird durch Automatisierung nicht besser – nur schneller falsch. Und eine Funktion, deren Schritte unsauber geschnitten sind, kann bei Wiederholungen Schaden anrichten statt Zuverlässigkeit zu schaffen. Deshalb steht in unseren Projekten immer die ehrliche Frage nach Prozess und Entwicklungskompetenz vor dem Bau der ersten Funktion.
Ein typischer Verlauf: Es beginnt mit einer einzelnen Funktion, die eine bisher fragile Hintergrundaufgabe zuverlässig macht. Schnell folgen weitere, weil der Nutzen sichtbar wird. Nach einigen Monaten existiert eine ganze Sammlung von Funktionen, verwoben mit der eigenen Anwendung und verteilt über mehrere Entwickler. Genau an diesem Punkt entscheidet sich, ob Zuverlässigkeit zum Selbstläufer oder zur unübersichtlichen Last wird – besonders, weil die Abläufe untrennbar Teil der Software sind.
Wir empfehlen daher, schon früh eine schlanke Übersicht anzulegen: Welche Funktion reagiert auf welches Event, welche Systeme berührt sie, welche Daten verarbeitet sie und wer ist verantwortlich. Diese Dokumentation kostet wenig Aufwand, ist aber die Grundlage, um die Abläufe wartbar zu halten und fundiert über Grenzen, Kosten und mögliche Konsolidierung zu entscheiden. Weil Inngest jeden Lauf nachvollziehbar protokolliert, ergänzt sich diese Übersicht ideal mit der eingebauten Beobachtbarkeit.
Zur Kostenlogik zuerst: Inngest rechnet im Kern nutzungsbasiert ab – die Zahl der ausgelösten Läufe und der ausgeführten Schritte ist der wesentliche Treiber, ergänzt um Pläne mit unterschiedlichen Kontingenten und Funktionen. Es gibt einen kostenlosen Einstiegsbereich sowie kostenpflichtige Pläne. Konkrete Preise nennen wir hier bewusst nicht, weil der Anbieter Pläne, Kontingente und Konditionen regelmäßig anpasst. Entscheidend ist das Verständnis der Logik dahinter – die bleibt stabiler als jede Zahl.
Der wichtigste Mechanismus: Kosten skalieren mit Zahl der Läufe und Schritte. Ein Ablauf, der selten ausgelöst wird und aus wenigen Schritten besteht, verbraucht wenig; ein Ablauf, der sehr häufig läuft oder aus vielen Schritten mit zahlreichen Wiederholungen besteht, verbraucht mehr. Für den Mittelstand heißt das: Bei überschaubarem Volumen bleibt Inngest günstig, bei hohem Durchsatz mit vielen Schritten lohnt eine ehrliche Hochrechnung, bevor produktiv skaliert wird. Wir erstellen diese Hochrechnung in Projekten standardmäßig – erwartete Läufe, multipliziert mit der typischen Zahl der Schritte pro Lauf – damit die tatsächlichen Kosten sichtbar werden, bevor ein Ablauf produktiv geht. Wichtig ist zudem, Wiederholungsgrenzen zu setzen, damit ein dauerhaft fehlschlagender Schritt nicht unbemerkt Kosten treibt.
Datenschutzrechtlich ist der zentrale Ausgangspunkt: Inngest ist ein US-amerikanischer SaaS-Anbieter. Bei der Nutzung des Cloud-Angebots werden Events, Schritt-Ergebnisse und Zustandsdaten durch die Infrastruktur des Anbieters geleitet und dort gespeichert. Bemerkenswert ist die Besonderheit des Betriebsmodells: Der eigentliche Code läuft in der eigenen Umgebung. Dennoch fließen die Nutzlasten der Events und die Zwischenergebnisse der Schritte durch die Cloud – und wo darin personenbezogene Daten stecken (Namen, E-Mail-Adressen, Kontaktdaten, Bestellinformationen), wird Inngest zum Auftragsverarbeiter, und es gelten die entsprechenden Anforderungen der DSGVO.
Als Unternehmen mit Sitz in den USA unterliegt Inngest grundsätzlich US-amerikanischem Recht. Auch wenn der Anbieter Schutzmaßnahmen und vertragliche Zusicherungen bietet, bleibt – wie bei allen US-Cloud-Diensten – ein rechtliches Restrisiko hinsichtlich behördlicher Zugriffsmöglichkeiten bestehen. Für viele Mittelständler ist dieses Risiko bei nicht hochsensiblen Daten und sauberer vertraglicher Grundlage tragbar, zumal der eigene Code in der eigenen Umgebung läuft und sich die durch die Cloud fließenden Nutzlasten bewusst klein halten lassen. Für besonders schützenswerte Datenkategorien, für Berufsgeheimnisträger oder für Unternehmen mit hohen Souveränitätsanforderungen bleibt der US-Cloud-Kern jedoch ein gewichtiges Gegenargument – hier ist die genutzte Region ebenso zu prüfen wie die Frage, ob eine selbst gehostete Ausführung in Betracht kommt.
Eine Besonderheit von Orchestrierungsplattformen ist, dass Daten nicht nur durch Inngest, sondern auch durch die in den Schritten aufgerufenen Dienste fließen. Ein einziger Ablauf kann Daten aus einer europäischen Quelle beziehen, sie als Event durch die Inngest-Cloud leiten, in einem Schritt an eine externe Schnittstelle oder ein Sprachmodell senden und schließlich in einer Datenbank ablegen. Diese Kette muss vollständig betrachtet werden – Datenschutz endet nicht an der Inngest-Grenze. Wir kartieren in Projekten daher für jeden produktiven Ablauf den kompletten Datenfluss vom auslösenden Event bis zum letzten Schritt, ausdrücklich einschließlich der in den Schritten aufgerufenen Dienste. Ein wirksamer Hebel ist dabei, in Events und Schritt-Ergebnissen nur eine Kennung statt vollständiger personenbezogener Daten mitzuführen.
Wenn Datenhoheit und Souveränität im Vordergrund stehen, ist die genutzte Region der erste Prüfpunkt: Lässt sich die Verarbeitung in einer EU-Region betreiben, verringert das den grenzüberschreitenden Transfer erheblich. Da zentrale Bestandteile von Inngest quelloffen sind, kommt für Unternehmen mit sehr hohen Anforderungen zudem eine selbst gehostete Ausführung als DSGVO-konformere Option in Betracht – auch wenn dies mit zusätzlichem Betriebsaufwand verbunden ist und im Einzelfall beim Anbieter zu klären ist, welche Bestandteile in welchem Umfang selbst betrieben werden können. Wo dieser Weg nicht gangbar ist, prüfen wir mit Kunden alternativ selbst-hostbare Werkzeuge wie Temporal, die eine ähnliche dauerhafte Ausführung bieten und die Daten vollständig in der eigenen Infrastruktur halten. Die Entscheidung ist letztlich eine Abwägung zwischen der Bequemlichkeit der gemanagten Cloud und der Kontrolle über die eigenen Daten – und sollte bewusst getroffen werden.
