Temporal Nexus
Temporal Nexus is now Generally Available for Temporal Cloud and self-hosted deployments.
This page explains what Nexus is and how it works. To evaluate whether Nexus fits your use case, see the evaluation guide.
What is Nexus?
Nexus connects Temporal Applications across (and within) isolated Namespaces. Each team gets their own Namespace for security and fault isolation, while exposing a clean service contract for others to use through a Nexus Endpoint.
Designed for Durable Execution, Nexus combines a familiar SDK programming model with reliable execution, built-in observability, and multi-region connectivity in Temporal Cloud.
Nexus is peer-to-peer, not hierarchical. Caller and handler Workflows are siblings that communicate across Namespace boundaries.
Nexus connects caller and handler Namespaces through a Nexus Endpoint
How Nexus works
Services and Operations
A Nexus Service is a named collection of Nexus Operations that a team exposes. Operations abstract the underlying implementation - callers don't need to know whether an Operation starts a Workflow, sends a Signal, runs a Query, or executes other reliable code.
The Operation lifecycle supports two modes:
- Asynchronous - Starts a Workflow (same or different Task Queue, with optional Eager Start). Can run up to 60 days.
- Synchronous - Completes within the 10-second handler deadline. Use for Signals, Queries, Updates, or other reliable low-latency calls using the Temporal SDK Client.
Services and Operations are built with the Temporal SDK and typically collocated in the same Worker as the Temporal primitives they abstract, or in a dedicated router Worker using the router-queue pattern.
- Go | Java | Python | TypeScript | .NET
Endpoints and Registry
A Nexus Endpoint is a reverse proxy that decouples callers from handlers. Callers reference an Endpoint by name. The Endpoint routes requests to a target Namespace and Task Queue. Callers never need to know the handler's Namespace, Task Queue, or internal implementation.
Endpoints are managed in the Nexus Registry using the UI, CLI, or Cloud Ops API.
Queue-based Worker architecture
Nexus uses the same queue-based Worker architecture as the rest of Temporal. Handler Workers poll the Endpoint's target Task Queue for Nexus Tasks. If a Nexus Service is down, caller Workflows continue to schedule Operations - they process when the service is back up. No bespoke service deployments needed. Load balancing is automatic.
Nexus Workers poll the Endpoint's target Task Queue
See system interactions for the full request flow.
Built-in Nexus Machinery
When a caller Workflow executes a Nexus Operation, the Nexus Machinery handles delivery with at-least-once execution:
- Automatic retries with exponential backoff
- Rate limiting and concurrency limiting
- Circuit breaking (trips after 5 consecutive retryable errors)
- Automatic load balancing
The Machinery uses Nexus RPC on the wire - a protocol supporting arbitrary-duration Operations. You interact only with the Temporal SDK, not Nexus RPC directly.
Multi-level calls
Nexus calls chain across teams and Namespaces:
- Workflow A -> Nexus Op 1 -> Workflow B -> Nexus Op 2 -> Workflow C
Operational reference
- Nexus security - Access controls, secure connectivity, and payload encryption.
- Nexus execution debugging - Bi-directional linking, pending Operations, and tracing.
- Nexus error handling - Error types and how they surface in caller Workflows.
- Nexus metrics - SDK, Cloud, and OSS cluster metrics.
Public Preview features
The following Nexus features are currently in Public Preview.