Skip to main content

Temporal Nexus - Deploy to Production with Temporal Cloud

SUPPORT, STABILITY, and DEPENDENCY INFO

Temporal Nexus is in Public Preview for Temporal Cloud.

This Temporal Nexus guide covers the following topics:

Temporal Nexus is a feature of the Temporal platform designed to connect durable executions across team, Namespace, region, and cloud boundaries. It promotes a more modular architecture for sharing a subset of your team’s capabilities via well-defined service API contracts for other teams to use, that abstract underlying Temporal primitives, like Workflows, or execute arbitrary code.

Introduction to Nexus​

Why choose Temporal Nexus?

  • Fully integrated Temporal SDK experience
    • Run Nexus Services in a Worker, often the same Worker as underlying primitives.
    • Use Nexus Services from a Workflow.
    • Same queue-based Worker architecture, for Worker fleet load balancing.
  • Built-in Nexus machinery
    • Connects Nexus callers and handlers via Nexus Endpoints.
    • Automatic retries & circuit breaking.
  • Multi-region routing across Namespaces
    • Secure mTLS connectivity.
    • Endpoint access control.
  • Observability
    • Integrated into Workflow Event History.
    • Bi-direction linking for end-to-end debugging.
    • Metrics, traces, and logs.
  • Improved blast radius isolation
    • Each team can have it’s own Namespace.
    • Per-Namespace security & rate limits.
    • Easier troubleshooting with less noise.

Should you be using Temporal Nexus?

  • Modular design - Temporal Nexus enables a modular design that helps structure an application for fast growth and supports teams working on their own parts independently. If you want to decouple callers from handlers to enable moving a service to a different Namespace or Task Queue later, Nexus can encapsulate those implementation details to avoid breaking changes and cross-team coordination.

  • Teams working together - When there is no clear API contract between teams working in a large monolithic Namespace, it takes work to understand what Workflows can be called from other Workflows – or if a team has signed up to maintain that interface. This places a burden on both teams, and makes changes more difficult. Nexus Services define a clear contract that is suitable for sharing across teams, and cleanly separates the public interface from the internal implementation, providing a more curated experience for service consumers while protecting service authors.

  • Keeping things separate and secure - When all teams operate in the same monolithic Namespace, everything is available to everyone, and mis-behaving workers can trigger rate limits that affect all teams operating in that monolithic Namespace. Temporal Nexus enables service modules to run in arbitrary Namespaces, since all Nexus requests are routed via the Nexus Endpoint to the underlying target Namespace and Task Queue. Running a Nexus Service in its own Namespace allows tighter Namespace permissions and limits the blast radius of misbehaving workers.

  • Managing interactions across boundaries - When no clean boundary exists it is hard to manage concerns like security and rate-limiting. A Nexus Endpoint is an API Proxy or Gateway, that can act as a central point of control for these concerns. Temporal Cloud supports built-in rate-limiting and an Endpoint allowlist - with a roadmap to support finer-grained rate-limiting and access-control policies suitable for external callers.

  • Adapting as the application grows - Temporal Nexus enables a modular application design that can evolve as you grow. From refactoring service implementations, changing an endpoint to point at a different target Namespace, or splitting a Worker out to a different Task Queue, Temporal Nexus enables you to hide these implementation details and provide a curated Nexus Service contract for other teams to use, so you can grow your application faster with less breaking changes, downtime, and cross-team coordination.

Advantages of using Temporal Nexus:

  • Connect durable execution within and across Namespaces
  • Service contracts suitable for sharing across teams
  • Abstract underlying Temporal primitives, like Workflows – or execute arbitrary code.
  • Modular design that streamlines multi-team development
  • Improved security and blast-radius isolation with isolated Namespaces
  • Same queue-based Worker architecture, no bespoke service deployments needed