Um Temporal einzuordnen, hilft ein Blick auf das eigentliche Problem, das es löst. In vielen Unternehmen bestehen zentrale Abläufe aus vielen einzelnen Schritten, die über Minuten, Stunden oder sogar Tage verteilt sind: eine Bestellung annehmen, Zahlung prüfen, Ware reservieren, versenden, benachrichtigen. Jeder dieser Schritte kann scheitern – ein Dienst ist gerade nicht erreichbar, eine Schnittstelle antwortet nicht, ein Server wird neu gestartet. Klassischerweise muss ein Entwicklungsteam für jeden dieser Fälle selbst vorsorgen: Zwischenzustände in einer Datenbank speichern, Wiederholungen programmieren, hängengebliebene Vorgänge aufspüren. Genau diese fehleranfällige Fleißarbeit nimmt Temporal ab.
Die Kategorie, in die Temporal fällt, wird oft als Workflow-Orchestrierung oder eben Durable Execution bezeichnet. Anders als bei visuellen No-Code-Werkzeugen, die Fachanwender per Klick bedienen, richtet sich Temporal ausdrücklich an Entwicklerteams. Workflows werden nicht in einer grafischen Oberfläche zusammengeklickt, sondern in einer echten Programmiersprache geschrieben – als ganz normaler Code, der sich testen, versionieren und in bestehende Entwicklungsprozesse einbinden lässt.
Aus unserer Projektpraxis lässt sich die Zielgruppe klar umreißen. Temporal ist ideal für Organisationen, in denen eigene Softwareentwicklung stattfindet und in denen zugleich geschäftskritische, mehrstufige Prozesse zuverlässig laufen müssen – etwa in der Auftragsabwicklung, im Zahlungsverkehr, bei der Bereitstellung von Diensten oder bei der Datenverarbeitung über mehrere Systeme hinweg. Überall dort, wo ein hängengebliebener oder doppelt ausgeführter Vorgang echten Schaden anrichten würde, spielt Temporal seine Stärke aus.
Weniger geeignet ist Temporal für reine Fachabteilungen ohne Entwicklungskompetenz, die eine einfache, geführte Klick-Oberfläche für kleine Automatisierungen suchen. Für solche Szenarien sind No-Code-Werkzeuge zugänglicher und schneller startklar. Temporal ist kein „Automatisierungstool für alle“, sondern ein Fundament für belastbare Software – und es entfaltet seinen Wert nur, wenn ein Team es als solches versteht und betreibt.
Der Kern der Sache lässt sich an einem typischen Entwickler-Alptraum festmachen. Ein Prozess soll eine Zahlung auslösen, danach eine Bestätigung versenden und schließlich einen Datensatz aktualisieren. Zwischen Zahlung und Bestätigung stürzt der Server ab. Wurde die Zahlung schon ausgelöst? Darf man sie wiederholen, oder bucht man dann doppelt ab? Ohne besondere Vorkehrungen führen solche Situationen zu inkonsistenten Zuständen, doppelten Buchungen oder verlorenen Vorgängen – und zu langen, unangenehmen Fehlersuchen.
Temporal beantwortet diese Fragen strukturell: Die Plattform führt für jeden Workflow eine vollständige Historie aller bereits ausgeführten Schritte. Nach einem Absturz wird der Ablauf anhand dieser Historie exakt rekonstruiert und dort fortgesetzt, wo er stand – ohne bereits erledigte Schritte zu wiederholen. Der Entwickler schreibt seine Logik so, als könne nichts schiefgehen, und Temporal sorgt im Hintergrund dafür, dass die Realität mit dieser Annahme übereinstimmt. Diese Verschiebung der Verantwortung – von unzähligen manuellen Absicherungen hin zu einer garantierten Ausführung – ist der eigentliche Fortschritt.
Im Zentrum steht der Temporal-Dienst – historisch oft als Cluster oder Temporal Server bezeichnet. Er ist das Gedächtnis und der Taktgeber der Plattform: Er speichert die vollständige Historie jedes Workflows, verteilt anstehende Aufgaben und stellt sicher, dass jeder Schritt genau einmal ausgeführt wird. Um diesen Kern herum ordnen sich die weiteren Bausteine an, die zusammen ein zusammenhängendes System ergeben.
Ein Architekturmerkmal verdient besondere Aufmerksamkeit, weil es für die Datenschutzbewertung zentral ist: Der eigentliche Anwendungscode läuft niemals im Temporal-Dienst selbst, sondern immer in den Workern des Unternehmens. Der Dienst kennt nur die Abfolge der Ereignisse und die Daten, die zwischen den Schritten übergeben werden – er stößt Aufgaben an und speichert deren Ergebnisse, führt aber keine Geschäftslogik aus. Die eigentliche Arbeit, etwa der Aufruf einer Datenbank oder einer externen Schnittstelle, geschieht in den selbst betriebenen Workern. Diese Trennung erlaubt Architekturen, bei denen die sensibelsten Verarbeitungsschritte in der eigenen Infrastruktur bleiben, während der Orchestrierungsdienst gehostet wird – ein Punkt, auf den wir in Kapitel 09 zurückkommen.
Temporal gibt es in zwei grundlegenden Betriebsformen. Beim Self-Hosting betreibt das Unternehmen den quelloffenen Temporal-Dienst selbst – inklusive der zugrunde liegenden Datenbank – in der eigenen Infrastruktur, sei es im eigenen Rechenzentrum oder in einer selbst gewählten Cloud-Umgebung. Das bietet volle Kontrolle über Daten und Standort, verlangt aber echtes Betriebs-Know-how: Der Dienst ist ein anspruchsvolles verteiltes System, das überwacht, aktualisiert und skaliert werden will.
Als gehostetes Angebot steht Temporal Cloud bereit. Hier übernimmt der Anbieter den Betrieb des Dienstes, die Skalierung und die Verfügbarkeit; das Unternehmen betreibt weiterhin nur seine eigenen Worker. Das senkt den Betriebsaufwand erheblich und ist für viele Teams der pragmatische Weg. Zu beachten ist allerdings, dass Temporal Cloud von einem US-amerikanischen Anbieter betrieben wird – die Wahl der Region und die datenschutzrechtliche Bewertung sind daher gesondert zu klären.
Temporal besetzt eine sehr bestimmte Nische. Es ist kein Konkurrent zu No-Code-Automatisierern, die Fachabteilungen bedienen, und auch kein klassisches Werkzeug zur Datenpipeline-Orchestrierung. Es positioniert sich als Fundament für zuverlässige Anwendungslogik: dort, wo Software langlaufende, mehrstufige und geschäftskritische Prozesse abbilden muss und wo Zuverlässigkeit nicht verhandelbar ist. Der bewusste Verzicht auf eine grafische Modellierung zugunsten von echtem Code ist dabei Programm – Temporal will Teil des Software-Entwicklungsprozesses sein, nicht daneben stehen.
Das wichtigste Begriffspaar ist Workflow und Activity. Der Workflow enthält die Ablauflogik – das „Was in welcher Reihenfolge“ – und muss bestimmten Regeln folgen, damit Temporal seinen Zustand zuverlässig rekonstruieren kann. Deshalb darf ein Workflow selbst keine unvorhersehbaren Dinge tun, etwa direkt eine externe Schnittstelle aufrufen. Solche Seiteneffekte gehören in Activities. Eine Activity ist der Ort, an dem die eigentliche Arbeit mit der Außenwelt passiert: der API-Aufruf, der Datenbankzugriff, das Versenden einer E-Mail.
Diese Trennung ist zunächst gewöhnungsbedürftig, aber genau sie ermöglicht die Zuverlässigkeit. Ein typisches Beispiel aus der Auftragsabwicklung: Der Workflow beschreibt die Reihenfolge „Zahlung prüfen, Ware reservieren, Versand anstoßen, Kunde benachrichtigen“. Jeder dieser Schritte ist eine Activity. Fällt der Versanddienst kurz aus, wiederholt Temporal nur diese eine Activity nach den festgelegten Regeln – die bereits geprüfte Zahlung und die reservierte Ware bleiben unangetastet. Der Workflow läuft am Ende garantiert zu Ende, ohne dass ein Entwickler die Ausfallszenarien einzeln absichern musste.
Drei Mechanismen machen Temporal besonders mächtig. Retries fangen vorübergehende Störungen ab, ohne dass eine Zeile Fehlerbehandlung geschrieben werden muss – man legt lediglich fest, wie oft und in welchen Abständen wiederholt werden soll. Timer erlauben es, einen Workflow verlässlich pausieren zu lassen; eine Wartezeit von 30 Tagen ist ebenso selbstverständlich wie eine von 30 Sekunden, und sie übersteht jeden Neustart. Und über Signals kann ein laufender Workflow auf externe Ereignisse warten – etwa auf eine menschliche Freigabe – und erst dann fortfahren.
Aus diesen Bausteinen entstehen Abläufe, die mit klassischer Programmierung nur mit großem Aufwand realisierbar wären: ein Genehmigungsprozess, der tagelang auf eine Entscheidung wartet; ein Abo-Zyklus, der monatlich eine Zahlung anstößt; ein mehrstufiger Datenimport, der bei jedem Teilschritt gegen Ausfälle abgesichert ist. Wir prüfen in Projekten stets, welche dieser Mechanismen ein Anwendungsfall wirklich braucht – nicht jeder Prozess benötigt die volle Bandbreite, aber wo er sie braucht, gibt es kaum eine elegantere Lösung.
Ein unterschätzter Vorteil ist die vollständige Event-Historie. Temporal protokolliert jeden Schritt jedes Workflows lückenlos: welche Activity wann mit welchem Ergebnis lief, wann ein Timer ansetzte, wann ein Signal eintraf. In der Weboberfläche lässt sich diese Historie einsehen, was die Fehlersuche erheblich vereinfacht – man sieht exakt, an welcher Stelle ein Prozess hängt oder scheiterte. Für geschäftskritische Abläufe ist diese Transparenz ein wesentlicher Betriebsvorteil und oft auch für Nachweispflichten wertvoll.
Temporal bringt selbst keine Sprachmodelle mit und ist kein KI-Werkzeug im engeren Sinn. Sein Beitrag ist ein anderer: Es orchestriert die Schritte, aus denen eine KI-gestützte Anwendung besteht, und macht sie zuverlässig. Ein Aufruf an ein Sprachmodell wird schlicht als Activity ausgeführt – mit allen Vorteilen, die Temporal dafür bereithält: automatische Wiederholung bei Zeitüberschreitungen, sauberes Warten und eine lückenlose Historie jedes Schritts.
KI-Aufrufe sind ein Paradebeispiel für Schritte, die gerne scheitern: Modelle antworten langsam, Anfragen laufen in Zeitüberschreitungen, Dienste sind zeitweise überlastet oder Kontingente erschöpft. In klassischer Programmierung führt das zu komplizierter Fehlerbehandlung, halb fertigen Abläufen und teuren Doppelaufrufen. Als Temporal-Activity ausgeführt, wird ein solcher Aufruf nach klaren Regeln wiederholt, ohne dass bereits erledigte Schritte des Gesamtprozesses erneut laufen. Ein mehrstufiger Ablauf – etwa: Dokument aufbereiten, an ein Modell senden, Antwort prüfen, Ergebnis speichern – bleibt so auch bei einzelnen fehlgeschlagenen KI-Aufrufen stabil und kommt zuverlässig zum Ende.
Besonders wertvoll ist dies bei langlaufenden KI-Jobs: der Verarbeitung großer Dokumentmengen, aufwendigen Analysen über viele Datensätze oder Prozessen, die menschliche Zwischenprüfungen enthalten. Ein solcher Job kann Stunden dauern und viele Teilschritte umfassen – Temporal sorgt dafür, dass er einen Serverausfall in der Mitte übersteht und exakt dort weitermacht, wo er unterbrochen wurde. Das erspart teure Neuberechnungen und macht die Kosten kalkulierbar.
Ein jüngerer Schwerpunkt ist der Einsatz von Temporal als Grundlage für KI-Agenten – also Anwendungen, in denen ein Sprachmodell in mehreren Schritten selbstständig Werkzeuge aufruft, Zwischenergebnisse bewertet und weiterarbeitet. Solche agentischen Abläufe sind naturgemäß mehrstufig, langlaufend und fehleranfällig: Jeder Werkzeugaufruf kann scheitern, und der Zustand des Agenten muss über viele Schritte hinweg erhalten bleiben. Genau das ist die Kernkompetenz von Temporal. Ein Agent, der als Temporal-Workflow modelliert ist, behält seinen Kontext auch über Abstürze hinweg, wiederholt einzelne Werkzeugaufrufe kontrolliert und lässt sich in seiner gesamten Entscheidungshistorie nachvollziehen.
Der Reiz liegt darin, dass die schwierigen Zuverlässigkeitsfragen agentischer Systeme – Zustandsverwaltung, Wiederaufnahme, Nachvollziehbarkeit – von einer bewährten Plattform übernommen werden, statt selbst gebaut werden zu müssen. Das Konzept ist mächtig, aber jung. Wir raten dazu, agentische Ansätze zunächst in gut überwachbaren Szenarien einzusetzen, in denen ein Mensch kritische Ergebnisse kontrolliert, bevor sie wirksam werden.
In der Praxis empfehlen wir einen nüchternen Blick. Temporal lohnt sich für KI-Prozesse dann, wenn diese langlaufend, mehrstufig und geschäftskritisch sind – wenn also ein abgebrochener oder doppelt ausgeführter KI-Job echten Schaden oder hohe Kosten verursachen würde. Für einen einzelnen, kurzen Modellaufruf innerhalb einer sonst simplen Automatisierung ist Temporal dagegen überdimensioniert; hier genügt ein schlankeres Werkzeug. Der Mehrwert entsteht durch die Zuverlässigkeit und Nachvollziehbarkeit komplexer Abläufe, nicht durch die KI-Anbindung an sich.
Wir prüfen in Projekten daher zwei Fragen: Erstens, ob der KI-Prozess wirklich die Zuverlässigkeitsgarantien braucht, die Temporal bietet – oder ob ein einfacher, direkter Aufruf genügt. Zweitens, welche Daten dabei an welchen Modell-Anbieter fließen, denn dieser Aspekt ist datenschutzrechtlich gesondert zu bewerten. Diese beiden Fragen verhindern, dass Temporal aus technischer Begeisterung an Stellen eingesetzt wird, an denen es weder nötig noch verhältnismäßig ist.
Der erste und wichtigste Baustein sind die SDKs, die Programmbibliotheken für die unterstützten Sprachen. Offiziell werden Go, Java, Python, TypeScript und .NET unterstützt. Diese Breite ist ein bedeutender Vorteil: Ein Team kann Temporal in seiner bevorzugten Sprache und mit seinem bestehenden Technologie-Stack einsetzen, ohne eine neue Sprache lernen zu müssen. Und weil Workflows und Activities normaler Code sind, steht in ihnen das gesamte Bibliotheks-Ökosystem der jeweiligen Sprache offen.
Hier liegt der grundlegende Unterschied zu No-Code-Plattformen. Wo diese vorgefertigte Bausteine für einzelne Apps anbieten, integriert Temporal über Code: Eine Activity kann jede Datenbank ansprechen, jede REST- oder gRPC-Schnittstelle aufrufen, jede Client-Bibliothek eines Dienstes nutzen. Damit ist praktisch jedes System erreichbar, für das es eine Programmierschnittstelle oder eine Bibliothek gibt – interne Anwendungen ebenso wie externe Dienste. Der Preis dafür ist, dass diese Integration von Entwicklern geschrieben werden muss; es gibt keinen fertigen Klick-Baustein. Der Vorteil ist grenzenlose Flexibilität und volle Kontrolle darüber, was genau passiert.
Praktisch heißt das: Selbst branchenspezifische oder selbst entwickelte Systeme, für die es bei No-Code-Werkzeugen nie eine fertige Integration geben wird, lassen sich mit Temporal sauber anbinden. Diese Offenheit ist einer der Hauptgründe, warum technische Teams die Plattform schätzen – sie stoßen nicht an die Grenzen eines vorgegebenen Baukastens.
Ein Bereich, in dem Temporal besonders stark ist, ist die Beobachtbarkeit. Neben der bereits erwähnten Event-Historie und der Weboberfläche stellt Temporal Kennzahlen bereit, die sich in gängige Überwachungssysteme einspeisen lassen. Damit fügt sich die Plattform in eine professionelle Betriebsumgebung ein: Metriken über laufende Workflows, Fehlerraten und Verzögerungen lassen sich zentral auswerten und mit Warnschwellen versehen. Für einen verlässlichen Betrieb geschäftskritischer Prozesse ist diese tiefe Einsicht kein Luxus, sondern Voraussetzung.
Weil Temporal-Workflows normaler Code sind, fügen sie sich nahtlos in die etablierten Werkzeuge der Softwareentwicklung ein. Sie liegen in der Versionsverwaltung, durchlaufen Code-Reviews, werden mit automatisierten Tests abgesichert und über die üblichen Bereitstellungspipelines ausgeliefert. Diese Einbettung unterscheidet Temporal grundlegend von Werkzeugen, deren Workflows in einer proprietären Oberfläche leben und sich schlecht versionieren oder testen lassen. Für Teams mit reifer Entwicklungspraxis ist das ein erheblicher Vorteil; für Teams ohne solche Praxis ist es zugleich eine Voraussetzung, die erst geschaffen werden muss.
Prefect und Dagster stammen aus der Welt der Datenverarbeitung. Ihr Zuhause sind Datenpipelines: das regelmäßige Verschieben, Transformieren und Aufbereiten von Daten, oft im Kontext von Analytik und Data Engineering. Sie sind stark darin, Abhängigkeiten zwischen Verarbeitungsschritten zu modellieren, Läufe zu planen und die Ergebnisse zu überwachen. Beide sind auf Python ausgerichtet und passen hervorragend in datengetriebene Teams.
Temporal hat einen anderen Schwerpunkt. Es geht nicht in erster Linie um Datenpipelines, sondern um die zuverlässige Ausführung beliebiger geschäftskritischer Abläufe – oft langlaufend, oft mit Interaktion und Warten auf Ereignisse. Die Faustregel, die wir in Projekten nutzen: Wenn es um das periodische Aufbereiten von Daten geht, sind Prefect oder Dagster meist die natürlichere Wahl. Wenn es um langlaufende, zustandsbehaftete Geschäftsprozesse mit hohen Zuverlässigkeitsanforderungen geht – Bestellungen, Zahlungen, mehrstufige Provisionierung – spielt Temporal seine Stärke aus. Die zusätzliche Sprachbreite über Python hinaus ist dabei ein weiteres Unterscheidungsmerkmal.
Camunda kommt aus der Welt des Geschäftsprozessmanagements und arbeitet klassisch mit der Modellierungssprache BPMN – Prozesse werden als Diagramme dargestellt, die auch fachliche Anwender lesen und teilweise gestalten können. Das ist ein großer Vorteil, wenn Prozesse zwischen Fachabteilung und IT abgestimmt werden müssen und die grafische Darstellung Teil der Kommunikation ist. Camunda deckt ebenfalls langlaufende Prozesse ab und bietet reiche Werkzeuge rund um Aufgabenmanagement und menschliche Prozessschritte.
Der Unterschied liegt in der Philosophie: Camunda stellt das visuelle Prozessmodell in den Mittelpunkt, Temporal den Code. Wo Prozesse stark von fachlicher Modellierung, Genehmigungsketten und der Zusammenarbeit mit Nicht-Technikern geprägt sind, ist Camunda oft die passendere Wahl. Wo die Logik komplex, entwicklernah und tief in eine Anwendung eingebettet ist, spielt Temporal seine Stärken aus. Beide sind belastbar für geschäftskritische Abläufe – sie sprechen nur unterschiedliche Zielgruppen und Denkweisen an.
Der große Reiz von Temporal liegt darin, dass das Unternehmen die Betriebsform frei wählen kann – anders als bei reinen SaaS-Werkzeugen, die nur in der Cloud des Anbieters existieren. Wer maximale Kontrolle und Datenhoheit will, betreibt den quelloffenen Dienst selbst. Wer den Betriebsaufwand minimieren will, nutzt Temporal Cloud. Diese Wahlfreiheit ist ein zentraler Vorteil und zugleich eine Entscheidung, die bewusst getroffen werden sollte.
Beim Self-Hosting betreibt das Unternehmen den Temporal-Dienst inklusive der zugrunde liegenden Datenbank in der eigenen Infrastruktur. Der Vorteil ist eindeutig: Daten und Verarbeitung bleiben vollständig unter eigener Kontrolle, der Standort ist frei wählbar, und es besteht keine Abhängigkeit von einem externen Anbieter für den Kern der Orchestrierung. Für Unternehmen mit hohen Souveränitätsanforderungen ist das oft das entscheidende Argument.
Dem steht ein realer Aufwand gegenüber. Der Temporal-Dienst ist ein anspruchsvolles verteiltes System, das fachkundig aufgesetzt, überwacht, aktualisiert und skaliert werden muss. Ohne Team mit entsprechendem Betriebs-Know-how – etwa im Umgang mit Container-Orchestrierung und Datenbanken – wird Self-Hosting schnell zur Last. Wir empfehlen diesen Weg nur dort, wo die Betriebskompetenz vorhanden ist oder aufgebaut wird und wo die Datenhoheit den Mehraufwand rechtfertigt.
Temporal Cloud nimmt dem Unternehmen den Betrieb des Dienstes ab. Der Anbieter kümmert sich um Verfügbarkeit, Skalierung und Aktualisierung; das Unternehmen betreibt weiterhin nur seine eigenen Worker. Das senkt die Einstiegshürde erheblich und ist für viele Teams der pragmatische Weg, um schnell produktiv zu werden. Zu bedenken ist, dass Temporal Cloud von einem US-amerikanischen Anbieter betrieben wird – Region, Serverstandort und Datentransfer sind daher datenschutzrechtlich sorgfältig zu prüfen (siehe Kapitel 09). Die Trennung von Dienst und eigenem Code hilft hier: Sensible Verarbeitung kann in den eigenen Workern verbleiben.
Aus unserer Projektpraxis hat sich ein schrittweises Vorgehen bewährt, das den technischen 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 laufenden Workflows, das saubere Behandeln von Fehlern und – gerade bei langlaufenden Workflows – der sorgsame Umgang mit Änderungen am Workflow-Code. Weil ein Workflow tage- oder wochenlang laufen kann, muss eine Code-Änderung so eingeführt werden, dass bereits laufende Instanzen nicht durcheinandergeraten. Temporal bietet dafür Mechanismen zur Versionierung; ihr korrekter Einsatz gehört zu den wichtigsten Betriebsdisziplinen.
Ein weiterer Punkt betrifft die Datenbank hinter dem Dienst. Beim Self-Hosting ist ihr Betrieb – Sicherung, Skalierung, Pflege – Teil der eigenen Verantwortung; bei Temporal Cloud übernimmt das der Anbieter. In beiden Fällen gilt: Auch eine so belastbare Plattform enthebt niemanden der Verantwortung für die eigene Logik. Ein Workflow ist nur so gut wie der Prozess, den er abbildet – und ein schlecht durchdachter Prozess wird durch Zuverlässigkeit nicht besser, sondern nur zuverlässig falsch.
Auffällig ist ein Muster: Temporal glänzt dort, wo Zuverlässigkeit über einen längeren Zeitraum gefragt ist – mehrstufige Abläufe, Warten auf Ereignisse, die Konsistenz über mehrere Systeme hinweg. Sobald ein Prozess über einen einzigen, kurzen Schritt hinausgeht und geschäftskritisch ist, spielt die Plattform ihre Stärke aus. Der Mehrwert entsteht nicht durch Bedienkomfort, sondern durch die strukturelle Vermeidung einer ganzen Klasse teurer Fehler.
Wichtig für die Erwartungshaltung: Der Nutzen realisiert sich nur, wenn Entwicklungskompetenz vorhanden ist und der Anwendungsfall die Zuverlässigkeitsgarantien wirklich braucht. Für einfache, kurze Automatisierungen ist Temporal überdimensioniert – dort wäre ein schlankeres Werkzeug schneller und günstiger. Deshalb steht in unseren Projekten immer die ehrliche Frage nach Anwendungsfall und Kompetenz vor dem Bau des ersten Workflows.
Ein typischer Verlauf: Es beginnt mit einem einzelnen kritischen Prozess, dessen Zuverlässigkeit heute Kopfzerbrechen bereitet. Läuft dieser erste Workflow stabil, wächst schnell das Vertrauen, weitere geschäftskritische Abläufe auf dieselbe Grundlage zu stellen. Nach einigen Monaten existiert eine ganze Landschaft zuverlässiger Prozesse – oft von mehreren Entwicklern gepflegt. Genau an diesem Punkt entscheidet sich, ob die Investition trägt.
Wir empfehlen daher, von Beginn an die Regeln guter Softwareentwicklung anzuwenden: Workflows testen, Änderungen bewusst versionieren, den Zweck jedes Workflows dokumentieren und festlegen, wer im Fehlerfall verantwortlich ist. Weil Temporal-Workflows normaler Code sind, greifen die etablierten Praktiken – ein Vorteil gegenüber Werkzeugen, deren Abläufe in einer proprietären Oberfläche schwer nachvollziehbar bleiben. Diese Disziplin ist der Unterschied zwischen einer belastbaren Prozesslandschaft und einer Sammlung schwer wartbarer Sonderlösungen.
Zur Kostenlogik zuerst: Weil Temporal quelloffen ist, fällt für die Software selbst beim Self-Hosting keine Lizenzgebühr an. Die Kosten entstehen hier durch den Betrieb – die benötigte Infrastruktur für Dienst und Datenbank sowie den Personalaufwand für Aufsetzen, Überwachung und Pflege. Dieser Betriebsaufwand ist real und sollte nicht unterschätzt werden: „kostenlos“ bezieht sich auf die Lizenz, nicht auf den Gesamtaufwand.
Bei Temporal Cloud zahlt das Unternehmen dagegen für den gehosteten Dienst – üblicherweise verbrauchsabhängig, orientiert an der Nutzung. Dafür entfällt der eigene Betriebsaufwand für den Dienst. Konkrete Preise nennen wir hier bewusst nicht, weil der Anbieter Modelle und Konditionen regelmäßig anpasst. Entscheidend ist das Verständnis der Logik dahinter – die bleibt stabiler als jede Zahl.
Der wichtigste Mechanismus unterscheidet sich je nach Betriebsform. Beim Self-Hosting skalieren die Kosten mit dem Infrastruktur- und Personalaufwand: Je größer und anspruchsvoller der Betrieb, desto höher die laufenden Kosten für Server, Datenbank und Fachpersonal. Bei Temporal Cloud skalieren die Kosten mit der Nutzung – mit der Zahl und Komplexität der ausgeführten Workflows. Für den Mittelstand heißt das: Bei überschaubarem Volumen und vorhandener Betriebskompetenz kann Self-Hosting attraktiv sein; wo diese Kompetenz fehlt, ist die gehostete Variante trotz laufender Gebühren oft die wirtschaftlichere Gesamtrechnung. Wir erstellen diese Gesamtbetrachtung in Projekten standardmäßig, bevor eine Betriebsform festgelegt wird – inklusive des oft unterschätzten Personalaufwands beim Self-Hosting.
Datenschutzrechtlich ist der zentrale Ausgangspunkt die Betriebsform. Beim Self-Hosting in der eigenen Infrastruktur bleiben Dienst und Daten vollständig unter eigener Kontrolle – ein starkes Argument für Datenhoheit und eine DSGVO-konforme Gestaltung, weil sich die Verarbeitung vollständig in der EU beziehungsweise im eigenen Rechenzentrum halten lässt. Nutzt ein Unternehmen dagegen Temporal Cloud, kommt ein US-amerikanischer Anbieter ins Spiel, und es gelten die Anforderungen an eine Auftragsverarbeitung sowie an einen möglichen Datentransfer.
Hier liegt eine der größten Stärken von Temporal im Vergleich zu reinen SaaS-Automatisierern: Weil die Plattform quelloffen und selbst betreibbar ist, kann ein Unternehmen sie vollständig in der eigenen Infrastruktur betreiben – on-premises oder in einer selbst gewählten EU-Cloud. In dieser Konstellation verlassen die Daten die eigene Kontrolle nicht, ein Datentransfer in Drittländer entfällt, und die datenschutzrechtliche Bewertung vereinfacht sich erheblich. Für Unternehmen mit hohen Souveränitätsanforderungen, für Berufsgeheimnisträger oder für besonders schützenswerte Datenkategorien ist dies oft das entscheidende Argument.
Wird stattdessen Temporal Cloud genutzt, gilt das, was für US-Cloud-Dienste allgemein gilt: Der Anbieter unterliegt grundsätzlich US-amerikanischem Recht, und trotz Schutzmaßnahmen und vertraglicher Zusicherungen bleibt ein rechtliches Restrisiko hinsichtlich behördlicher Zugriffsmöglichkeiten. Wichtig ist hier die bereits beschriebene Architektur: Da der eigene Code in den eigenen Workern läuft und der Dienst primär die Orchestrierung übernimmt, lässt sich durch bewusste Gestaltung begrenzen, welche Daten überhaupt in den gehosteten Dienst gelangen. Die Wahl einer EU-Region und eine sorgfältige Datenminimierung können das Risiko weiter verringern. Wo diese Maßnahmen nicht ausreichen, ist das Self-Hosting die datenschutzkonformere Alternative.
Eine Besonderheit von Orchestrierungsplattformen ist, dass Daten nicht nur durch Temporal, sondern auch durch die von den Activities aufgerufenen externen Dienste fließen. Ein einziger Workflow kann Daten aus einer europäischen Quelle ziehen, sie in einer Activity an eine externe Schnittstelle senden und schließlich in einem dritten System ablegen. Diese Kette muss vollständig betrachtet werden – Datenschutz endet nicht an der Temporal-Grenze. Wir kartieren in Projekten daher für jeden produktiven Workflow den kompletten Datenfluss vom Start bis zum letzten Schritt, ausdrücklich einschließlich der in Activities aufgerufenen Dienste und KI-Modelle. Die Entscheidung zwischen der Bequemlichkeit der gehosteten Cloud und der Kontrolle des Self-Hostings sollte bewusst und informiert getroffen werden.
