Temporal

Temporal is a durable execution platform for building distributed applications that survive failures without extra code to handle them. This repository is the Temporal server itself, written in Go. It's for backend developers and platform teams who need reliable orchestration of long-running business logic, background jobs, or multi-step processes across services, and who want to write that logic as regular code instead of a state machine or DAG config file.

The server executes units of application logic called Workflows. When a process fails partway through, Temporal automatically retries the failed step and resumes execution from where it left off, rather than restarting the whole process or losing state. Application code (Workflows, Activities, Workers) lives outside this repo, in one of Temporal's supported SDKs (Go, Java, and others), while this repo provides the backend service those SDKs talk to.

Key features

• Durable execution: Workflows keep their state and progress across crashes, deploys, and infrastructure failures, with automatic retry of failed operations.
• Language-agnostic workflow logic: Write Workflows and Activities as ordinary code in Go, Java, or other supported SDKs, instead of YAML or a visual DSL.
• Built-in retries and timeouts: Failure handling (retries, backoff, timeouts) is configured declaratively rather than hand-rolled with try/catch and queues.
• CLI and Web UI: The temporal CLI manages namespaces and workflows from the terminal; the Web UI gives visibility into running and completed workflow executions.
• Local dev server: temporal server start-dev spins up a full server plus dependencies for local development, no external infra required.
• Distributed cron and scheduling: Supports scheduled and recurring workflow execution alongside on-demand invocation.
• Mature lineage: Forked from Uber's Cadence and maintained by the original creators, with production use behind it.

Ideal use cases

Temporal fits well when you're orchestrating multi-step business processes that must survive partial failures: order fulfillment pipelines, payment processing, data pipelines with retries, deployment or provisioning workflows, and long-running approval or saga-style transactions across microservices. It's also a good fit for distributed cron jobs where you need visibility into execution history and failure handling that a plain scheduler doesn't give you.

It's less of a fit for simple, short-lived request/response services where a message queue or a basic job runner already does the job. Running your own Temporal server also means operating a distributed system (server, persistence store, and dependencies), so for small projects or prototypes, using Temporal Cloud or a lighter-weight tool may be less overhead than self-hosting. If your logic is stateless and doesn't need durability guarantees across failures, the operational cost of running this server probably isn't worth it.

Installation

The quickest way to run Temporal locally is through the Temporal CLI, which starts a pre-built server image with all dependencies:

brew install temporal
temporal server start-dev

Check the Temporal CLI docs for other installation methods (non-Homebrew platforms, etc.).

Once the server is running, interact with it using the CLI:

temporal operator namespace list
temporal workflow list

Open the Web UI at http://localhost:8233 to inspect workflow executions visually.

To build actual applications, clone the sample repositories for Go or Java and run them against your local server. These include HelloWorld-style examples as well as more advanced scenarios.

For building and running the Temporal Server itself from source (rather than the pre-built binary), see CONTRIBUTING.md and the architecture docs in the docs/architecture directory.