Directus + Inngest: KI- und Background-Workflows zuverlässig auslagern

Directus Flows gehören zu den leistungsfähigsten Low-Code-Funktionen der Plattform. Für viele Automatisierungen reichen sie vollkommen aus.

Doch spätestens bei KI-Anwendungen, Bildverarbeitung oder langlaufenden Integrationen stoßen klassische Flows an Grenzen.

Ein OpenAI-Aufruf dauert länger als erwartet. Eine Bildanalyse verarbeitet hunderte Dateien. Eine externe API antwortet nicht zuverlässig. Oder ein Workflow muss nach einem Fehler exakt an der richtigen Stelle fortgesetzt werden.

Genau für diese Szenarien wurde Inngest entwickelt.

Inngest ergänzt Directus um eine durable Workflow Engine mit automatischen Wiederholungen, Replay-Funktionen und langlaufenden Prozessen. Dadurch lassen sich KI-Workflows und Background Jobs zuverlässig außerhalb der Directus-Instanz ausführen.

In diesem Beitrag zeigen wir, wie die Kombination aus Directus und Inngest funktioniert und wann sich die zusätzliche Komplexität tatsächlich lohnt.

Warum nicht alles in Directus Flows?

Viele Teams versuchen zunächst, sämtliche Automatisierungen direkt in Directus abzubilden.

Das funktioniert erstaunlich lange gut.

Irgendwann treten jedoch typische Probleme auf.

Flow-Timeout-Grenzen

Flows eignen sich hervorragend für:

  • Validierungen
  • Statuswechsel
  • Benachrichtigungen
  • API-Aufrufe

Problematisch werden dagegen Prozesse mit langer Laufzeit.

Typische Beispiele:

  • OpenAI Content-Generierung
  • Übersetzungen
  • Dokumentenanalyse
  • Bildverarbeitung

Je länger ein Workflow läuft, desto höher wird die Fehleranfälligkeit.

Single-Process-Lock bei langen Tasks

Flows laufen innerhalb der Directus-Umgebung.

Blockierende Prozesse können Ressourcen binden, die eigentlich für andere Aufgaben benötigt werden.

Typische Symptome:

  • Langsame Reaktionszeiten
  • Hohe CPU-Last
  • Warteschlangen
  • Verzögerte Events

Kein nativer Retry mit Backoff

Externe APIs sind nie vollständig zuverlässig.

Probleme entstehen beispielsweise durch:

  • Rate Limits
  • Netzwerkfehler
  • Timeouts
  • Kurzfristige Ausfälle

Ein fehlgeschlagener API-Aufruf benötigt häufig:

  • Retry
  • Exponential Backoff
  • Fehlerbehandlung
  • Wiederaufnahme

Genau hier liegen die Stärken von Inngest.

 

Inngest in 60 Sekunden

Inngest ist eine moderne Workflow Engine für ereignisgesteuerte Anwendungen.

Der Fokus liegt auf:

  • Durable Workflows
  • Langlaufenden Prozessen
  • Wiederholbarkeit
  • KI-Workloads

Was ist eine Durable Workflow Engine?

Ein Workflow bleibt jederzeit reproduzierbar.

Wenn ein Fehler auftritt:

  • wird der Zustand gespeichert
  • der Workflow pausiert
  • später exakt an derselben Stelle fortgesetzt

Dadurch entstehen deutlich robustere Prozesse.

Step Functions und Replay-Semantik

Statt einen Prozess als monolithischen Ablauf zu behandeln, wird er in einzelne Schritte aufgeteilt.

Beispiel:

  1. Artikel erstellen
  2. Übersetzung erzeugen
  3. Bild analysieren
  4. Ergebnis speichern

Fällt Schritt 3 aus, müssen die Schritte 1 und 2 nicht erneut ausgeführt werden.

Inngest startet exakt an der fehlgeschlagenen Stelle.

Inngest Dev Server lokal

Für die Entwicklung stellt Inngest einen lokalen Dev Server bereit.

Vorteile:

  • Lokales Debugging
  • Workflow Replay
  • Event Testing
  • Schnelle Iteration

Dadurch lassen sich komplexe Workflows deutlich einfacher entwickeln als mit klassischen Cron-Jobs.

 

Integration-Architektur

Die Kombination aus Directus und Inngest folgt einem einfachen Muster.

Directus Flow → Outgoing Webhook → Inngest Trigger

Ablauf:

Directus
↓
Flow Trigger
↓
Webhook
↓
Inngest Event

Directus bleibt das führende System.

Inngest übernimmt lediglich die Ausführung komplexer Prozesse.

Inngest Function ruft Directus zurück

Nach erfolgreicher Verarbeitung erfolgt die Rückgabe an Directus.

Inngest
↓
REST API
↓
Directus

Beispielsweise:

  • Status aktualisieren
  • Datei speichern
  • Ergebnisse hinterlegen

State-Management über Directus Collections

Bewährt hat sich ein separates Workflow-Schema.

Collection: workflow_jobs

Felder:

  • workflow_id
  • status
  • started_at
  • finished_at
  • correlation_id
  • result

Dadurch bleibt der Workflowstatus jederzeit sichtbar.

 

Beispiel: KI-Content-Pipeline

Ein typisches Einsatzszenario besteht in der automatisierten Content-Verarbeitung.

Trigger bei neuem Artikel

Collection: articles

Neuer Datensatz: status = draft

Directus löst einen Flow aus.

Der Flow sendet ein Event an Inngest.

Schritt 1: OpenAI-Übersetzung

Inngest ruft OpenAI auf.

Ziel:

  • Englisch
  • Französisch
  • Spanisch

Der Workflow wartet auf das Ergebnis.

Schritt 2: Bild-Tagging

Anschließend werden die Bilder analysiert.

Mögliche Services:

  • OpenAI Vision
  • AWS Rekognition
  • Google Vision

Ergebnisse:

  • Tags
  • Kategorien
  • Alt-Texte

Schritt 3: Status-Update in Directus

Nach erfolgreicher Verarbeitung: status = translated

Directus erhält die aktualisierten Daten zurück.

Der gesamte Prozess läuft außerhalb der Directus-Instanz.

Replay-Verhalten bei Fehlern

Nehmen wir an:

Die Bildanalyse schlägt fehl.

Inngest speichert automatisch:

  • Workflow-Zustand
  • Schrittstatus
  • Eingabedaten

Nach der Wiederholung startet ausschließlich: Bildanalyse

Die Übersetzungen werden nicht erneut erzeugt.

Genau diese Replay-Semantik unterscheidet Inngest von klassischen Flows.

 

TypeScript-Beispiel mit Directus SDK

Eine typische Inngest Function sieht wie folgt aus:

import { Inngest } from "inngest";
import { createDirectus, rest } from "@directus/sdk";

const inngest = new Inngest({
id: "content-pipeline"
});

const directus = createDirectus(
process.env.DIRECTUS_URL
).with(rest());

export const processArticle = inngest.createFunction(
{ id: "process-article" },
{ event: "article.created" },
async ({ event, step }) => {

const translation = await step.run(
"translate",
async () => {
return await translateArticle(event.data);
}
);

await step.run(
"update-directus",
async () => {
return directus.request(
updateItem(
"articles",
event.data.id,
{
status: "translated"
}
)
);
}
);

return translation;
}
);

Die Kombination aus TypeScript, Directus SDK und Inngest ermöglicht sehr robuste Workflow-Architekturen.

Beobachtbarkeit

Komplexe Workflows benötigen Transparenz.

Inngest Dashboard

Das Dashboard zeigt:

  • Laufende Workflows
  • Fehler
  • Retries
  • Ausführungsdauer
  • Event-Historie

Dadurch lassen sich Probleme schnell identifizieren.

Korrelations-IDs in Directus speichern

Ein bewährtes Muster:

Jeder Workflow erhält eine eindeutige ID.

Beispiel: correlation_id

Diese wird sowohl in Directus als auch in Inngest gespeichert.

Vorteile:

  • Einfacheres Debugging
  • Nachvollziehbarkeit
  • Support-freundlich

 

Kosten und Limits

Nicht jeder Workflow benötigt Inngest. Vor der Einführung sollten Aufwand und Nutzen bewertet werden.

Inngest Free Tier

Für viele Projekte reicht der kostenlose Tarif aus.

Typische Einsatzgebiete:

  • Prototypen
  • Interne Tools
  • Kleine KI-Anwendungen

Self-Hosting-Optionen

Je nach Anforderung kann Inngest auch selbst betrieben werden.

Vorteile:

  • Volle Kontrolle
  • Eigene Infrastruktur
  • Compliance-Anforderungen

 

Wann lohnt sich Inngest für Directus?

Nicht jede Automatisierung sollte ausgelagert werden. Das häufigste Anti-Pattern besteht darin, sämtliche Flows nach Inngest zu verschieben.

Gute Kandidaten

  • KI-Workflows
  • Bildanalyse
  • Dokumentenverarbeitung
  • Langlaufende Prozesse
  • Mehrstufige Agenten-Systeme

Schlechte Kandidaten

  • Statuswechsel
  • Validierungen
  • Kurze API-Aufrufe
  • Benachrichtigungen
  • CRUD-Automatisierungen

Die 30-Sekunden-Regel

Eine praktische Faustregel:

Wenn ein Workflow länger als 30 Sekunden dauert oder von externen Diensten abhängt: → Inngest

Wenn der Workflow innerhalb weniger Sekunden abgeschlossen werden kann: → Directus Flow

 

Inngest oder n8n?

Eine häufige Frage lautet:

Wann sollte ich Inngest statt n8n verwenden?

Szenario n8n Inngest
SaaS-Integrationen
CRM-Prozesse
ERP-Anbindungen
Durable Workflows
KI-Agenten Eingeschränkt
Replay bei Fehlern Begrenzt
Langlaufende Jobs Begrenzt

Kurz gesagt:

  • n8n verbindet Systeme
  • Inngest betreibt langlebige Prozesse

Viele moderne Architekturen nutzen beide Werkzeuge parallel.

 

Fazit

Directus Flows sind für die meisten Automatisierungen vollkommen ausreichend.

Sobald jedoch KI-Anwendungen, Bildverarbeitung oder langlaufende Prozesse ins Spiel kommen, entstehen neue Anforderungen:

  • Wiederholbarkeit
  • Zuverlässigkeit
  • Fehlerisolierung
  • Skalierbarkeit

Genau hier ergänzt Inngest die Stärken von Directus.

Die Kombination aus Directus als Datenplattform und Inngest als Workflow Engine ermöglicht robuste KI- und Background-Prozesse, ohne die Directus-Instanz mit langlaufenden Aufgaben zu belasten.

Inngest wird besonders interessant, wenn aus klassischen Automatisierungen echte KI-Agenten werden. In diesem Beitrag zeigen wir, wie sich AI-Agent-Workflows auf Basis von Directus aufbauen lassen.

FAQ

Was unterscheidet Inngest von n8n?

n8n ist primär eine Integrations- und Automatisierungsplattform. Inngest ist eine Durable Workflow Engine für langlaufende und fehlertolerante Prozesse.

Wann lohnt sich Inngest für Directus?

Vor allem bei KI-Anwendungen, Bildverarbeitung, Dokumentenanalyse oder anderen Prozessen mit längeren Laufzeiten und externen Abhängigkeiten.

Kann ich Inngest selbst hosten?

Ja. Je nach Anforderung kann Inngest selbst betrieben oder als Managed Service genutzt werden.

Wie handhabe ich Idempotenz?

Verwende eindeutige Event-IDs und speichere Workflow-Zustände in Directus. Dadurch können Events mehrfach verarbeitet werden, ohne unerwünschte Nebeneffekte zu erzeugen.

Sollte ich alle Directus Flows nach Inngest verschieben?

Nein. Kurze und einfache Prozesse bleiben meist besser direkt in Directus Flows. Inngest eignet sich vor allem für komplexe oder langlaufende Workflows.

Kann Inngest mit OpenAI und anderen KI-Diensten arbeiten?

Ja. Gerade KI-Anwendungen gehören zu den häufigsten Einsatzszenarien für Inngest, da lange Laufzeiten und Wiederholungen zuverlässig verarbeitet werden können.