Cloud Parts

Temporal

An open-source durable execution engine: you write workflows as ordinary code and they survive crashes.

What it is
Workflow orchestration,Persistence: state, events and replay
Type
Open source
Made by
Temporal Technologies
License
MIT
Facts checked
5 October 2026
Website Source code

What it is

In Temporal you write a workflow as normal code in Go, Java, TypeScript, Python, .NET, PHP, Ruby or Rust. Anything with side effects, such as charging a card or sending an email, goes in an activity. Your own worker processes poll task queues on the Temporal Service, run the code, and report each step back, and the service records every step in the workflow’s event history. If a worker dies, another one replays that history to rebuild the workflow’s state and carries on from the same line. A 30-day sleep or a wait for a signal uses no worker while it waits.

Because of replay, workflow code must be deterministic: no direct network calls, clock reads or random numbers outside the SDK’s own APIs. Activities get timeouts and automatic retries with backoff. The server is open source under the MIT licence, written in Go, and stores its state in PostgreSQL, MySQL or Cassandra. Temporal Cloud runs the service for you, priced by actions, while your workers and data stay in your own infrastructure.

Why teams pick it

  • Workflows are real code: loops, branches, error handling and unit tests in your own language
  • Built for long-running processes: durable timers, signals and queries let a workflow wait days for a person or another system
  • Self-host it or use Temporal Cloud with the same SDKs, and run your workers on Kubernetes, VMs, serverless platforms or your own hardware
  • You can replay a production event history locally to debug exactly what happened

Watch out for

  • The determinism rule takes discipline, and changing code while old executions are still running needs explicit versioning
  • One execution’s history is capped at 51,200 events or 50 MB; long loops must restart themselves with Continue-As-New
  • Self-hosting means running a distributed service plus its database, and tuning both
  • You run and scale the workers yourself, even on Temporal Cloud

Alternatives

What all workflow orchestration have in common →
AWS Step FunctionsAWSAWS’s serverless workflow engine: state machines in JSON that call AWS services directly.Cloudflare WorkflowsCommercialDurable execution on Cloudflare Workers: a workflow is ordinary TypeScript or Python code split into steps, and each step’s result is saved so a failed run retries that step and carries on instead of starting over.PrefectOpen sourceA Python workflow orchestrator where a pipeline is an ordinary function decorated with `@flow`, with retries, caching, schedules and a UI added around it.

How it fits with other technologies

A workflow that charges a card, then waits three days (Python SDK) · python

import asyncio
from datetime import timedelta
from temporalio import activity, workflow

@activity.defn
async def charge_card(order_id: str) -> str:
    return f"receipt-{order_id}"  # call the payment API here: side effects live in activities

@workflow.defn
class OrderWorkflow:
    @workflow.run
    async def run(self, order_id: str) -> str:
        receipt = await workflow.execute_activity(charge_card, order_id, start_to_close_timeout=timedelta(seconds=30))
        await asyncio.sleep(timedelta(days=3).total_seconds())  # a durable timer that survives restarts
        return receipt

See it in a real stack

No architecture uses Temporal yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Slides· September 2025How and Why Datadog moved from cloud-managed to self-managed PostgresNick Canzoneri, Datadog, at PGConf NYC 2025Slides from a talk on why a company running hundreds of Postgres clusters across several clouds left managed services for its own Postgres platform on Kubernetes, how it moved a whole region, and what got better and worse. The stack is Patroni (with ZooKeeper for leader election), WAL-G backups, a Helm chart rather than an operator, and Temporal workflows for automation. Useful before you weigh RDS-style convenience against running Postgres yourself.
All resources →
Where it came from2012–2026

Temporal’s founders worked on the same problem for two decades. Maxim Fateev joined Amazon in 2002, when the entire website was one binary, and his team built the publish/subscribe infrastructure that grew into SQS. Queues alone didn’t make communication between services reliable, so he went on to lead the Simple Workflow Service (SWF), and Samar Abbas joined the team that brought SWF to the public in 2012. SWF was conceptually advanced, but “developers found it complex and cumbersome.” Abbas then built the open-source Durable Task Framework at Microsoft, which became a key dependency of Azure Functions.

In 2015 the two reunited at Uber and built Cadence, a workflow engine in which workflows are ordinary code. It grew to more than 100 internal use cases in three years before going open source in 2017. In 2019 they left Uber to build Temporal, which started as a fork of Cadence, and Temporal 1.0 shipped on September 29, 2020.

Temporal named its idea Durable Execution: the platform keeps a workflow’s full state, so the code carries on after any failure. Interest jumped with AI agents, which run long multi-step tasks, and in September 2026 the company raised $550 million at a $12.55 billion valuation.

Why it’s built this way

Workflows as ordinary code, not a DSL
SWF taught its creators that power without a good developer experience doesn’t get adopted. In Go, Java or Python you keep loops, tests and your usual tools; Fateev says you end up “writing pure business logic”.
An event history replayed by workers
The service records every step, and a fresh worker rebuilds a workflow’s state by re-running the code against that history. That gives crash recovery and exact debugging, and it’s why workflow code must be deterministic.
Your workers run your code
The service stores state and hands out tasks, while your code and data stay on your own machines, so the same workflow runs against a self-hosted server or Temporal Cloud.
Open source from the start
Fateev had watched powerful technologies stagnate at Amazon when they were kept proprietary, so Cadence was fully open source and Temporal kept it under the MIT licence.

Timeline

  1. 2012

    Fateev and Abbas take Amazon SWF public

  2. 2015

    They start Cadence at Uber

  3. 2017

    Cadence is open-sourced

  4. 2019

    They leave Uber to build Temporal, a fork of Cadence

  5. 2020

    Temporal 1.0 ships in September

  6. 2022

    Temporal Cloud moves from developer preview to expanded access

  7. 2026

    $550M Series E at a $12.55B valuation

Sources16 · facts checked 5 October 2026

Improve this page on GitHub