temporal

Temporal is an open-source durable execution platform that ensures workflows keep running through crashes, network outages, and infrastructure failures without losing state. Originating as a fork of Uber’s Cadence project, it is now developed by Temporal Technologies and powers some of the most demanding distributed systems at companies like Stripe, Coinbase, and Netflix.

At its core, Temporal implements event-sourced workflow orchestration: every workflow execution maintains an append-only event history that can be replayed at any time to reconstruct exact state. This means workers can crash and restart without any data loss, and developers write ordinary sequential code rather than managing complex state machines or retry loops.

The platform is structured as a cluster of internal services—Frontend, History, Matching, and Internal Workers—each handling a distinct concern. The History Service owns per-workflow state and shards it across the cluster for horizontal scalability. The Matching Service manages task queues that SDK workers poll for work. Client SDKs in Go, Java, Python, TypeScript, PHP, Ruby, and .NET communicate with the cluster over gRPC.

Self-hosting Temporal requires running the server alongside a persistence backend (PostgreSQL, MySQL, Cassandra, or SQLite for development) and optionally Elasticsearch for advanced workflow visibility. Temporal Cloud is the fully managed alternative, eliminating operational overhead while offering the same programming model.

What You Get

• Durable Workflow Execution - Workflows are persisted as append-only event histories that survive crashes and restarts, resuming exactly where they left off without developer intervention.
• Multi-Language SDKs - Write workflows and activities in Go, Java, Python, TypeScript, PHP, Ruby, or .NET with first-class SDK support and official sample repositories for each language.
• Automatic Retry Policies - Configure fine-grained retry schedules with exponential backoff, jitter, and maximum attempt limits for activities and child workflows, eliminating manual retry boilerplate.
• Temporal Web UI - Browser-based dashboard accessible at http://localhost:8233 for viewing running workflows, inspecting event histories, filtering by status, and debugging failures visually.
• Temporal CLI - Full command-line tooling to start workflows, send signals, query state, list namespaces, and perform operational tasks like termination and forced completion.
• Pluggable Persistence Backends - Swap between PostgreSQL, MySQL, Cassandra, or SQLite for workflow state storage, and optionally Elasticsearch or OpenSearch for advanced visibility queries.
• Worker Versioning and Safe Deploys - Deploy new workflow code versions without downtime using versioning APIs, continue-as-new patterns, and worker deployment version management.
• Kubernetes-Native Deployment - Official Helm charts and Docker images for deploying Temporal clusters on Kubernetes with support for horizontal scaling, health checks, and rolling upgrades.
• Nexus Integration - Built-in HTTP-based cross-namespace and cross-cluster orchestration with tokenized callbacks, enabling workflows to span organizational boundaries.
• Dynamic Configuration - Runtime-adjustable configuration via dynamic config files or APIs, allowing tuning of rate limits, timeouts, matching behavior, and feature flags without restarts.

Common Use Cases

• Payment and financial transaction processing - A fintech platform uses Temporal to ensure every payment completes or rolls back cleanly, surviving partial failures across banking APIs and internal microservices with full audit trails via event history.
• AI agent pipeline orchestration - An AI product team coordinates multi-step LLM inference chains, tool calls, and human-in-the-loop review steps across hours or days, with automatic retries on rate-limit errors and persistent state between steps.
• Customer onboarding and KYC workflows - A compliance-heavy SaaS product manages identity verification, document review, third-party API calls, and async approval steps in a single durable workflow that survives weekend downtime and API outages.
• E-commerce order fulfillment - A retailer coordinates inventory reservation, payment capture, warehouse picking, shipping label generation, and returns processing across separate microservices, each step retried independently on failure.
• Infrastructure provisioning automation - A platform engineering team uses Temporal to manage long-running Terraform or cloud API provisioning sequences that may take minutes or hours, with compensating transactions on failure.
• Distributed cron and scheduled jobs - A data team replaces fragile cron infrastructure with Temporal schedules that guarantee exactly-once execution semantics and provide observability into missed, overlapping, or failed runs.

Under The Hood

Architecture Temporal follows an event-sourced, service-decomposed architecture in which four specialized internal services—Frontend, History, Matching, and Internal Workers—collaborate through gRPC to execute durable workflows. The History Service is the heart of the system, owning per-workflow event histories and sharding them across nodes using consistent hashing for horizontal scalability. The Matching Service manages task queues, routing workflow and activity tasks to the worker processes that poll them. Dependency wiring throughout the codebase uses Uber’s fx framework for constructor-based injection, ensuring clean interfaces between layers and making unit testing of individual components straightforward. The CHASM (Chasm Hierarchical Automaton State Machine) subsystem is an emerging second-generation state storage engine that supports versioned state graphs for non-linear workflow replay and branching execution, sitting alongside the established event-history model.

Tech Stack Temporal is written entirely in Go (requiring 1.26+), with CGO disabled to produce fully static, container-friendly binaries. Cross-service communication uses Protocol Buffers over gRPC, with a grpc-gateway layer exposing HTTP/JSON endpoints where needed. Persistence is abstracted behind a driver interface supporting PostgreSQL and MySQL via pure Go SQL drivers, Cassandra via gocql, and SQLite via modernc.org/sqlite for zero-dependency local development. Elasticsearch and OpenSearch are supported as visibility stores for advanced workflow search queries. Observability is first-class: OpenTelemetry provides distributed tracing with OTLP exporters, and Prometheus metrics are emitted natively. Zap handles structured logging. The build system uses Make, with buf for proto linting and code generation, GoReleaser for multi-platform binary packaging, and Makefile-driven CI automation.

Code Quality With over 820 test files across the codebase, Temporal maintains an extensive test suite powered by testify/suite for structured test organization and uber-go/mock for interface-based mocking of internal dependencies. Error handling is explicit and typed throughout, using gRPC status codes and domain-specific service error types rather than stringly-typed or swallowed errors. The project enforces consistent naming through domain-aligned packages, and the protobuf-generated types provide a strong compile-time contract layer across service boundaries. Inline comment density in the history and matching services is high, explaining non-obvious sharding decisions and consistency guarantees. CI runs linting, proto validation, and test suites on every pull request, and the project publishes a code coverage report via Codecov.

What Makes It Unique Temporal’s most distinctive technical contribution is guaranteeing durable execution through deterministic workflow replay: developers write ordinary imperative code and the platform handles fault tolerance by reconstructing workflow state from its event history on any failure. The CHASM engine extends this further with versioned state graphs that support non-linear replay patterns, enabling more complex branching automata than traditional event sourcing allows. The native Nexus protocol provides bidirectional HTTP orchestration across namespace and cluster boundaries with built-in callback routing and tokenized completions, going beyond typical workflow platforms that treat cross-service calls as opaque activity tasks. The dynamic task category registry and pluggable persistence abstractions mean new capabilities—like the OpenSearch visibility store added in v1.30—can be shipped without service restarts or core code changes.

Self-Hosting

Temporal is licensed under the MIT License, which is one of the most permissive open-source licenses available. You are free to use, modify, and distribute the software for any purpose, including commercial use, without any copyleft obligations. There are no open-core restrictions, feature-gated enterprise tiers, or license keys required to run the full Temporal server—the entire codebase is available under the same terms.

Running Temporal yourself requires meaningful infrastructure investment. At minimum you need a persistence backend (PostgreSQL or MySQL recommended for production; Cassandra is also supported for high-scale deployments), and optionally Elasticsearch or OpenSearch if you want advanced workflow search beyond the basic visibility store. The Temporal cluster itself runs as a set of horizontally scalable services that you deploy via Docker Compose for development or Helm charts for Kubernetes. You are responsible for database maintenance, backups, schema migrations between versions, monitoring, and ensuring high availability of both the Temporal services and their dependencies. For a serious production deployment, this is non-trivial: schema migrations must be run manually before version upgrades, and the release notes for each version should be reviewed carefully for breaking changes (the v1.30 release, for example, included significant Docker image and Helm chart breaking changes).

Temporal Cloud is the fully managed alternative operated by Temporal Technologies. It removes all of the above operational burden and adds enterprise features including SLA-backed uptime, automated backups, managed schema upgrades, support contracts, and a multi-tenant namespace model with fine-grained access control. Cloud pricing is consumption-based (per action and storage). For teams who want the Temporal programming model without the operational overhead, or who need SLA guarantees they cannot provide themselves, Temporal Cloud is the pragmatic choice. The self-hosted path remains fully featured for teams with the infrastructure expertise and a preference for on-premises or air-gapped deployments.