Temporal: durable execution for mission-critical workflows in Java, Go, TS, Python

What is Temporal?

Temporal is an MIT-licensed workflow-as-code platform, founded 2019 in Seattle as a spin-off from Uber (Maxim Fateev, Samar Abbas – the creators of Uber Cadence). Market position is unambiguous: Temporal delivers "Durable Execution" – workflows guaranteed to run to completion, even if servers crash, networks fail, or processes restart. State and code are persisted by the Temporal server, and the worker resumes the workflow exactly where it left off.

The concept differs from Zapier, Make, or n8n. Temporal is not a drag-and-drop tool but a backend framework with SDKs in Java, Go, TypeScript, Python, .NET, Ruby, and PHP. Developers write workflows as regular functions in their language; Temporal handles retry, timeouts, state management, versioning, and multi-datacentre replication. As of May 2026 workflow versions 1.x and Temporal Server 1.27+ are in production.

Commercially two paths: self-hosted under MIT license (free, Docker-Compose or Kubernetes setup on own infrastructure) and Temporal Cloud (managed service, from USD 100/month for smallest tiers, scaling by actions). Self-host is the usual choice for mid-market companies – the cloud only pays off at very high volumes or for teams without ops know-how for the Temporal server.

The architecture consists of the Temporal Server (several microservices: Frontend, History, Matching, Worker) plus a database layer (Postgres, MySQL, or Cassandra). Workers run as own processes, usually inside the business applications themselves – Temporal itself does not execute business code but orchestrates it.

For a Swiss fiduciary Temporal is rarely directly applicable – the learning curve and the setup are overkill for 5-15 production workflows. Temporal makes sense where long runtimes (hours, days, weeks) with complex state and guaranteed retry are essential: client onboarding with several stages of external checks, billing reconciliation, multi-step provisioning of cloud resources.

Why it matters

Temporal solves a problem that other workflow tools cannot solve: durable execution with guaranteed correctness. Classic example: an order workflow covers payment (Stripe charge), shipping (logistics API), confirmation mail, and inventory update. If the server crashes after payment but before shipping booking, the workflow must reliably continue – without double payment, without missed shipping.

In Zapier, Make, or n8n such a workflow runs synchronously in one engine; a crash mid-way leaves an undefined state. Anyone building retry logic has to manage idempotency keys in every external system and run manual reconciliation tools. In Temporal the server stores every workflow step with input and output; after a crash the workflow resumes exactly at the next unexecuted activity.

For SMEs and fiduciaries the use cases are narrower than with n8n. Three realistic levers: first – complex client onboarding processes with AML check. An onboarding workflow can take days (UID verification, external database queries, credit check, manual approval). With Temporal the workflow state stays persistent, every step is retry-capable, and the approval logic is part of the code.

Second – billing reconciliation. Stripe charges, invoices from Bexio, bank transactions via finstro or klarx – a daily reconciliation that identifies missing or duplicate bookings, with a manual correction loop. Temporal fits because every reconciliation run is idempotent and state (which receipts already processed) is cleanly persisted.

Third – multi-step cloud provisioning. When a fiduciary builds an own ERP setup for a new client (Bexio instance, cloud storage, SSO config, backup job, client training), that is a workflow with dozens of steps, external API calls, and retry logic. Temporal is a valid pick here – n8n is an alternative, but with many external systems with unclear failure modes Temporal wins on robustness.

The downside is clear: learning curve, setup effort, ops know-how. Anyone running Temporal in production has an engineering team with experience. For small fiduciary setups the investment is rarely justified.

How it works

A Temporal system has three main components: Temporal Server (orchestrator), Workers (execute workflow and activity code), and Clients (start workflows). The separation is fundamental: the server stores workflow state and decides which activity to execute next; workers pull tasks from task queues and execute the actual business code.

A workflow is a function in the application language (Python, Go, Java, TypeScript). The function contains the business logic – it calls activities, waits for signals, handles errors. Important: a workflow must be deterministic. Direct API calls or I/O are forbidden in workflow code; everything external has to move into activities. Activities are the non-deterministic functions – they make HTTP calls, DB queries, file operations.

The magic is the replay function. If the worker crashes, Temporal starts another worker and "replays" the workflow function – but instead of actually executing the activities, the server delivers the stored results from the workflow history. So the workflow reaches the exact same state as before the crash. From the next unexecuted activity, real execution resumes.

A typical example in TypeScript: a workflow "onboardClient" starts with client data. Step 1 calls activity "verifyUID" (against ZEFIX API). Step 2 calls activity "checkAML" (against compliance provider). Step 3 waits for an external signal (manual approval). Step 4 calls activity "createBexioCompany". Steps 1-2 take seconds, step 3 can take hours to days (manual approval), step 4 seconds again. The entire workflow is durable – even if the worker crashes between step 3 and step 4, it resumes exactly with step 4 after restart.

The SDK languages differ in maturity: Go and Java are oldest, TypeScript and Python have been stable since 2022, .NET and Ruby came 2023, PHP 2024. Functionally all SDKs are equivalent; choice depends on the application tech stack.

Temporal has no connectors like Zapier or n8n. Every integration runs as an activity calling the right SDK of the third system (Stripe SDK, HubSpot SDK, AWS SDK). That is more boilerplate than visual tools, but fully typed and version-controlled in exchange.

Temporal self-hosted in 5 steps

1. 01Prepare the Docker-Compose stack: Temporal Server (Frontend, History, Matching, Worker), Postgres as DB, Temporal Web as UI, Caddy/Nginx as reverse proxy.
2. 02Install the SDK for the application language (TypeScript, Python, Go, or Java) and integrate a first worker process inside the existing application.
3. 03Write the first workflow: define a function in TypeScript/Python, activities as separate functions, workflow test with replay helper.
4. 04Define task queues: one queue per worker type, register workflows, connect workers to the queue. Scaling happens via multiple workers.
5. 05Set up monitoring: Temporal Web for workflow history and debugging, Prometheus scraper on the server metrics, alert when workflow failure rate exceeds 1%.

When to use Temporal

Temporal is the right pick when (a) the workflow is mission-critical (money, compliance, customer experience), (b) runtime can range from hours to weeks, (c) state is complex (several intermediate results, external approvals), and (d) the team has engineering know-how.

Concrete cases: order processing in e-commerce (payment + shipment + inventory + mail), payment reconciliation in fintech, multi-step onboarding for regulated customers (KYC, AML, compliance checks), cloud-resource provisioning (multi-step setup with rollback logic), data pipelines with long runtime and many failure modes.

For a Swiss fiduciary with 5-15 staff Temporal is rarely sensible directly. It becomes sensible at a fiduciary platform with hundreds of clients and automated onboarding, or at a SaaS solution using Temporal as workflow backbone. For standard client triage, invoice sorting, and VAT collection, n8n is the more pragmatic path.

For engineering teams in larger SMEs (50+ staff) with critical workflows, Temporal is an investment in future safety. Learning curve is 1-3 months, in exchange the platform scales into millions of workflows/day – no other tool on the list does that.

When not to use

Temporal is the wrong choice for simple SaaS wirings. Anyone building "Slack message on new Stripe charge" has 5 minutes of setup in Zapier, at least a day of engineering effort in Temporal (worker setup, activity implementation, workflow definition). For typical SME workflows the complexity is overkill.

Unsuited for no-code teams. There is no UI for workflow design – all workflows are written in code. Marketing or sales teams without engineering support cannot run Temporal themselves.

Does not fit small self-host setups. The server components (Frontend, History, Matching, Worker) plus a database need at least 4 vCPUs and 8 GB RAM, plus monitoring and ops know-how. For 5-15 production workflows that is oversized.

For simple data pipelines Temporal is oversized. Airflow or dbt are more efficient – Temporal is optimised for workflows with complex state and long runtime, not pure ELT batches.

For AI classification workflows without complex state (classify incoming mail, enter into CRM, Slack notification), Temporal is a sledgehammer for a pin problem. n8n, Make, or Activepieces are the right choice.

Trade-offs

FAQ

Related topics

Sources

1. Temporal documentation – concepts and SDKs · 2026-05
2. Temporal Cloud pricing page · 2026-05
3. Temporal on GitHub – MIT-licensed server · 2026-05
4. Temporal durable execution and replay semantics · 2026-04