Introducing Standalone Nexus Operations

Temporal was founded on a simple idea: you should be able to focus on your application logic and build what your users need. Temporal gives you an open programming model for doing that, while handling work scheduling, execution state, and recovery. Your work can retain its progress through failures and long waits without you building those systems yourself.

When we introduced Nexus, we extended that vision across services. You can build applications from reusable services, with durability built into how those services run and communicate. A payments team, for example, can build a shared payment service with Temporal and expose “collect a payment” through a defined contract that other teams can build on. The team owns its implementation; Temporal handles the routing, coordination, and durability of the service interaction.

Now, Standalone Nexus Operations opens that durable service model to more of the applications and agents you’re already building. Your backend, internal tool, or agent can call a Nexus service directly through the Temporal SDK, using the same service contract and implementation. You can bring that capability into your application while keeping its surrounding logic where it is.

We’re sharing this early look as the first story in the October Temporal Product Edition, ahead of Public Preview on November 1.

Call services built on Temporal directly from your existing application#

Suppose you’re adding checkout to an existing application. It needs to collect payments for new purchases, while your billing application needs the same capability for outstanding orders. Your team builds a shared payment service with Temporal and exposes a collectPayment operation through Nexus.

With Standalone Nexus Operations, your checkout backend calls that operation through the Temporal SDK. Checkout keeps its current framework and order logic. Billing can call the same operation, using the same service contract and implementation. Your team maintains the payment rules and provider integration in one place, so each new application can use that capability without rebuilding it.

Those applications also need a dependable way to learn the outcome when a payment takes longer than the original request or a connection fails.

Fire and forget with guaranteed reliability#

With Standalone Nexus Operations, calling the payment service directly still gives you Temporal’s built-in durability.

Coming back to our payments service example, once Temporal accepts the operation from the checkout service, it will track it independently of the original request. If a temporary connection failure prevents delivery to the payment service, Temporal will retry delivery within the operation’s timeout. If the payment then needs additional verification, the service can keep working after checkout returns a pending response.

Your backend gives the operation an ID and stores it with the order. In this example, client is a Temporal SDK client connected to Temporal, and paymentService defines the operations the payment service makes available.

Your backend starts the payment like this:

const payments = client.nexus.createServiceClient({
  endpoint: 'payments',
  service: paymentService,
});

await payments.startOperation(
  paymentService.operations.collectPayment,
  { orderId: 'order-123' },
  { id: 'payment-order-123' },
);

Starting the operation and waiting for its result are separate calls. When a later request needs the outcome, your backend uses the same client configuration to find the operation by ID:

const payment = client.nexus.getHandle('payment-order-123');
const result = await payment.result();

result() waits for completion and returns the result, or throws an error if the operation fails. Your backend can then use that outcome to update the order.

With this architecture, your checkout backend owns the order flow and decides what to do with the payment outcome. Temporal handles delivery retries and tracks the payment operation even if checkout disconnects or restarts.

Business logic stays in your code. Reliability and durability come from Temporal. That’s infrastructure your team no longer has to build, debug, or operate around each service call.

A new faster way to build and scale services for applications and agents#

Standalone Nexus Operations enters Public Preview on November 1.

Choose one capability you want your applications or agents to share. Follow our SDK guides for Go, Java, .NET, Python, or TypeScript to get a sample running in under 10 minutes, then add your service logic. Explore the feature documentation for the full capabilities.

Nexus advances Temporal’s vision for service-oriented applications: reusable services with durability built into how they run and communicate. As your application grows across services and teams, execution state, delivery retries, and operation tracking are part of the programming model, instead of infrastructure each team has to recreate.

Standalone Nexus Operations brings more of your existing applications and agents into that architecture. More capabilities are coming to make these services easier to build, share, and compose, so you can add new functionality to your applications and agents faster, with reliability and durability already built-in.