Connecting Workflows across teams and applications is critical for scaling distributed systems, but it must be done in a way that supports Durable Execution and integrated observability for reliable operation and execution debugging.

Existing solutions have notable limitations#

Direct Workflow-to-Workflow integrations are a leaky abstraction with high degree of coupling between caller and handler Workflows due to the lack of a service contract. They often require full write access to a target Namespace resulting in an overly permissive security posture. Child Workflows in Temporal Cloud must run in the same namespace, which means everyone has access to everything and the blast radius for misbehaving Workers is not isolated. Custom integrations with bespoke APIs and webhooks often have a high operational burden and require lots of boilerplate code that must be made reliable. Teams must agree on a common communication protocol that enables Durable Execution. Even if you create such a system, it often results in a disjoint execution debugging experience in production with manual Namespace traversal and log correlation.

Announcing Temporal Nexus#

We’re excited to announce Temporal Nexus, a built-in feature of the Temporal Platform to connect Temporal Applications across (and within) isolated Namespaces. Nexus is available in Public Preview both in the open source and Temporal Cloud. Nexus provides all the benefits of Durable Execution across team and application boundaries with improved modularity, security, debugging, and fault isolation.

Unlike other forms of inter-service communication, Nexus combines a familiar programming model with the resiliency of the Temporal Platform and its queue-based Worker architecture.

Teams like Netflix are using Nexus to eliminate the need for custom APIs and webhooks for cross-namespace communication and enable seamless, secure collaboration across teams.

Connect Temporal Applications#

Nexus is a fully integrated feature of the Temporal platform that enables cross-team, cross-domain, cross-namespace, and multi-region use cases:

Connect Temporal Applications - across team and Namespace boundaries Abstract Temporal primitives, like workflows, with clean service contracts Run Nexus services with Temporal’s queue-based Worker architecture Improve reliability with at-least-once and exactly-once execution guarantees Secure sensitive workflow state with isolated Namespaces for each team Streamline debugging and monitoring with integrated observability

Create Nexus Endpoints in the Nexus Registry#

Nexus Services are exposed from a Nexus Endpoint created in the Nexus Registry. Adding a Nexus Endpoint to the Nexus Registry deploys the Endpoint, so it is available at runtime to serve Nexus requests. The Nexus Registry is scoped to an Account in Temporal Cloud and scoped to a Cluster for self-hosted deployments.

A Nexus Endpoint is a reverse proxy that decouples the caller from the handler and routes requests to upstream targets. It currently supports routing to a single target Namespace and Task Queue. Nexus Services and Nexus Operations are often registered in the same Worker as the underlying Temporal primitives they abstract. Nexus connectivity across Namespaces is provided by the Temporal Service. Temporal Cloud supports Nexus connectivity within and across regions and has built-in access controls. Self-hosted Nexus connectivity is supported within a single Cluster and custom Authorizers may be used for access control.

Build and use Nexus Services#

Nexus has a familiar programming model to build and use Nexus Services using the Temporal SDK. The Nexus Operation lifecycle supports both synchronous and asynchronous Operations. It is suitable for low-latency and long-running use cases. Nexus Operations can be implemented with Temporal primitives, like Workflows, or execute arbitrary code.

Add a Nexus Service to an existing Worker#

Temporal SDKs have builder functions to create Nexus handlers like New-Sync-Operation and New-Workflow-Run-Operation that reduce boilerplate code, auto-wire callbacks and support bi-directional links for easier cross-namespace execution debugging. For example, the New-Workflow-Run-Operation SDK helper is used to build a Nexus Service with a Nexus Operation that starts a Workflow:

var MyOperation = temporalnexus.NewWorkflowRunOperation(  "my-operation-name",  MyWorkflowToExposeAsAnOperation,  func(       ctx context.Context,       input MyInput       options nexus.StartOperationOptions,  ) (client.StartWorkflowOptions, error) {                   return client.StartWorkflowOptions{                  ID: businessID(input),   }, nil  })service := nexus.NewService("my-service-name")_ = service.Register(MyOperation)myTemporalWorker.RegisterNexusService(service)myTemporalWorker.RegisterWorkflow(MyWorkflowToExposeAsAnOperation)

A Nexus Service is typically registered in the same Temporal Worker as the underlying Temporal primitives they abstract. The Worker polls the Endpoint's target Task Queue for Nexus requests to handle. This eliminates the need to run a bespoke API server, streamlines deployment and provides automatic load balancing.

Expose Nexus Services from a Nexus Endpoint#

For others to use a Nexus Service, it must be exposed from a Nexus Endpoint. This is done by creating a Nexus Endpoint in the Nexus Registry and configuring the Endpoint target to route Nexus requests to the Namespace and Task Queue that a Nexus Worker is polling. Multiple Nexus Services may be run on a single Task Queue. Nexus Endpoints may be managed using the Temporal UI, the CLI, or thttps://temporal.io//images.ctfassets.net/0uuz8ydxyd9p/34SiWWdvqQ45LWumvrOCe9/989f38c189aa292fd52cc507560eac77/IMG_0520.png189aa292fd52cc507560eac77/IMG_0520.png" alt="Endpoint nexus">

Use a Nexus Service from a caller Workflow#

Temporal SDKs currently support calling Nexus Operations from a caller Workflow. For example, in the Go SDK a Nexus Operation is invoked as follows:

func MyCallerWorkflow(ctx workflow.Context, input MyInput) (MyOutput, error) {  c := workflow.NewNexusClient("my-endpoint-name", "my-service-name") fut := c.ExecuteOperation(ctx, "my-operation-name", MyInput{Message: message}, workflow.NexusOperationOptions{})    var res MyOutput    if err := fut.Get(ctx, &res); err != nil {      return "", err  }   return res, nil}

Start building Nexus Services with the Temporal Go SDK and Java SDK quick start guides and code samples for the open source and Temporal Cloud.

Queue-based Worker architecture#

Nexus uses the Temporal queue-based Worker architecture and built-in Nexus machinery to ensure reliable execution of Nexus Operations. If a Nexus Service is down, a caller Workflow can continue to schedule Nexus Operations and they will be processed when the Service is up.

Built-in Nexus Machinery#

The built-in Nexus Machinery uses state-machine-based invocation and completion callbacks. It guarantees at-least-once execution and supports exactly-once execution using Workflow policy. Nexus provides automatic retries, circuit breaking, rate limiting, and load balancing.

What’s next#

The roadmap for Temporal Nexus includes:

Multi-cloud Nexus connectivity across AWS and GCP in Temporal Cloud. GA release of Nexus in 2025. Nexus support in all Temporal SDKs. Contract-first developer experience with IDL and code generation. Direct Nexus calls from external clients beyond a caller Workflow. Per-caller rate limiting on Nexus Endpoints. Terraform support for managing Nexus Endpoints Much more!

Get started with Nexus today!#

Learn how Nexus connects Temporal Applications and provides all the benefits of Durable Execution within and across Namespace boundaries with improved modularity, security, debugging, and fault isolation.