Inter-cluster invocation via Nexus

Developer Corner
1

We’re making follow-up investigations due to the outcome of Temporal in IoT context (with limited connectivity) - #5 by andrei.hu .

We have two running two Temporal instances (let’s say A and B). We would like to expose some operations from instance B, which can be then consumed by some workflows running on instance A. We don’t find the API to make this scenario possible, it feels that when we’re building up the worker, we cannot specify separately what instance we’re using for running our workflows and which one we’re using to consume Nexus services. The diagram in the documentation is clearly showing this usecase as a possiblity (Temporal Nexus | Temporal Platform Documentation).

We tried to interrogate the AI on the Slack forum to point us to the right direction, but it seems it is out of depth here. Can someone point us to the right direction?

Thanks in advance!

1 Like
2

Hi Everyone,

I am bumping this up, since we weren’t able to figure this out on our own since then, and it’s still blocking us somewhat. I think we would be able to work a limitation around, but we have the feeling is that Nexus solves this problem much better. We just can’t seem to find the API for it.

Best and sorry for the spam

3

Hi @andrei.hu yes you can make cross-cluster Nexus calls with experimental support for Nexus Endpoints with an External target. It’s briefly mentioned in the Temporal Docs and allows you to create a local proxy Nexus Endpoint in Instance A that targets the remote URL for a Nexus Endpoint in Instance B. This allows Caller Workflows in Instance A to use Nexus Services in Instance B.

Here’s a working example for External targets, in summary:

  • Instance A:
    • Caller Workflow → Local/Proxy Nexus Endpoint (billing) → External/remote target URL
  • Instance B:
    • Remote Nexus Endpoint (billing-remote) → Worker target ns/task queue → Handler Workflow

The temporal operator nexus endpoint create command provides an experimental --target-url flag for this purpose, that can be used as follows:

# create a local proxy Nexus Endpoint that targets an external `--target-url`

temporal operator nexus endpoint create \
  --name billing \
  --target-url "http://$HOST:$PORT/nexus/endpoints/$ENDPOINT_ID/services" \
  --description test123

Which results in a local proxy Nexus Endpoint (in Instance A), like this:

+ temporal operator nexus endpoint get --name billing
  ID                       043e0894-bd71-439f-81ba-223e6b6765dd
  Name                     billing
  CreatedTime              "2025-06-20T23:14:28.367208Z"
  LastModifiedTime         <nil>
  Target.External.URL      http://localhost:7243/nexus/endpoints/6f08a12a-7746-4685-b712-6128609a0710/services
  Target.Worker.Namespace
  Target.Worker.TaskQueue
  Description              test123

So effectively you’d need to manage local proxy Nexus Endpoints in each caller instance/cluster.

Also there are some limitations with the current experimental support for External targets:

  • The normal caveats of an experimental feature.
  • Nexus Endpoints with an External target doesn’t currently render in the UI (but CLI is fine)
  • Bi-directional Links for execution debugging won’t automatically resolve, since they assume the link to the handler Workflow is in the same Temporal instance as the caller Workflow.

We have improved multi-cluster Nexus support on the roadmap (including a multi-cluster Nexus Registry), but no specific timeframe just yet. Please let us know if this works for your use case and if there are any changes you’d like to see!

1 Like
4

Hi Phil,

Thanks for the response, this is excellent news for us. For the time being we’re not affected with the feature being experimental, we’re evaluating temporal and at this stage we don’t have to rely on stable features.