Temporal Platform Documentation

website·Indexed 42 days ago

https://docs.temporal.io/

Documentation for Temporal, an open-source durable execution platform. It covers core concepts like Activities and Workflows, activity operations (Pause, Reset, Terminate, Update Options), and a comprehensive AI Cookbook for building durable AI agents and systems using LLM integrations, tool calling, and frameworks like OpenAI, Claude, and Vercel AI SDK.

Tokens
850K
Snippets
2.9K
Records
5K
Agent score
92%

What's inside Temporal

  1. Overview of Temporal Service dynamic configuration

    Temporal Service supports dynamic configuration keys that can be updated and applied to a running service without requiring a restart. These keys allow for tuning rate limits, size limits, and retry defaults to optimize performance based on specific workload requirements. Overriding these values is optional; defaults are provided during service creation. Changes should be tested before being applied to production environments.
  2. Overview of legacy Worker Versioning (2023 draft)

    Legacy Worker Versioning (deprecated 2023 draft) allows developers to deploy incompatible changes to Workflow Definitions by assigning a Build ID (a free-form string) to Workers. The Temporal Server uses these Build IDs and associated version sets on a Task Queue to ensure that Workflow and Activity tasks are only processed by Workers with compatible code versions. This prevents nondeterministic errors when multiple versions of a Workflow coexist on the same Task Queue.
  3. Overview of Temporal Nexus Observability

    Temporal Nexus provides integrated observability within Temporal Cloud through three primary mechanisms: metrics for monitoring performance, execution debugging for tracing and operation tracking, and audit logging for tracking endpoint lifecycle changes.
  4. Overview of Temporal Cloud Projects

    Projects are an organizational layer within a Temporal Cloud Account that group related resources—such as Namespaces, Nexus endpoints, and Connectivity Rules—into a single operational boundary. They are used to align resources with organizational structures (e.g., by team, environment, or business unit) to delegate ownership and manage access at scale. Projects are for organization and authorization; they do not affect how Workflows execute inside a Namespace or restrict which Namespaces can call a Nexus Endpoint.
  5. Overview of Temporal Rust Standalone Activities

    Standalone Activities are Activities that run independently without being orchestrated by a Workflow. Unlike Workflow Activities, which are executed via ctx.execute_activity() within a Workflow Definition, Standalone Activities are executed directly from a Temporal Client. The definition and registration process for Standalone Activities is identical to that of Workflow Activities.
  6. Overview of tcld command categories

    The Temporal Cloud CLI (tcld) provides a suite of commands for managing Temporal Cloud resources. Key command categories include:

    • account: Account management
    • apikey: API key management
    • connectivity-rule: Connectivity rule configuration
    • feature: Feature management
    • generate-certificates: Certificate generation
    • login/logout: Session management
    • migration: Migration tools
    • namespace: Namespace management
    • nexus: Nexus endpoint management
    • request: Request handling
    • service-account: Service account management
    • user/user-group: User and group management
    • version: Check CLI version
  7. Overview of Context Propagation in Temporal Go SDK

    Context propagation allows developers to pass custom key-value data from a Client to Workflows, and from Workflows to Activities and Child Workflows, without manually adding the data to every function signature. This is typically used for request-scoped metadata such as tenant identifiers or authentication tokens.

    Note: For tracing context, use the built-in tracing integrations instead of implementing a custom propagator.

  8. Overview of Temporal Workflow message passing mechanisms

    Temporal Workflows act as stateful services that interact with external clients via three types of messages:

    • Queries: Read-only requests used to retrieve the current state of a Workflow. They are non-blocking and do not modify the Workflow state or history.
    • Signals: Asynchronous write requests used to trigger changes in a running Workflow. They follow a 'fire and forget' pattern; the sender cannot await a response or error.
    • Updates: Synchronous, tracked write requests. Unlike Signals, the sender can wait for a completion response or an error, and the request is validated by the Worker before being accepted into the Workflow history.
  9. Overview of the Temporal Python SDK Sandbox

    The Temporal Python SDK runs Workflow code in a sandbox environment to prevent non-determinism errors. It achieves this through global state isolation (using exec to compile and evaluate statements) and restrictions that block known non-deterministic library calls. If a non-deterministic event occurs, an exception is thrown and the Task Worker fails, preventing the Workflow from progressing until the code is fixed.
  10. Overview of Serverless Workers on Amazon Bedrock AgentCore Runtime

    On AgentCore Runtime, a Serverless Worker is a standard long-running Temporal Worker that operates within an AgentCore Runtime session. When the Worker Controller Instance (WCI) requires capacity, it invokes an AgentCore Runtime endpoint, which starts a Worker that connects to the Temporal Service and polls its Task Queue. This setup is currently in Pre-release and APIs may change.
  11. Overview of Temporal Nexus

    Temporal Nexus is a peer-to-peer communication system that connects Temporal Applications across isolated Namespaces. It allows teams to expose specific functionality via service contracts without revealing internal implementation details, enabling modularity and reuse across a platform. It leverages Temporal's durable execution, providing built-in observability, security, and multi-region connectivity in Temporal Cloud.
  12. Overview of Temporal Local Activities

    Local Activities execute the Activity function directly inside the Worker process currently running the Workflow Task. Unlike regular Activities, they bypass the Temporal server's scheduling and dispatching process, reducing per-Activity overhead to near zero. The result is bundled into the Workflow Task completion event. This is primarily used to reduce latency on hot-paths where multiple short, idempotent Activities are called in sequence.