Architecture and security

Wie es funktioniert

The Relay client — a lightweight binary installed on a machine inside your network — establishes a persistent, outbound-only TLS tunnel (port 443) to the Relay Server in Test Cloud. When a UiPath cloud service needs to reach one of your on-premises endpoints, the request travels from the cloud service through the Relay Server, down the tunnel to the Relay client, and from there across your local network to the target service.

Because the Relay client initiates all tunnel connections outbound, your network never accepts an inbound connection from the internet.

Connectivity flow

1. You register on-premises endpoints under a Relay Group in UiPath Administration. The endpoint list is stored in the Relay service.
2. The Relay client performs an authenticated discovery call to Test Cloud to retrieve the list of endpoints to expose.
3. The Relay client establishes a persistent control connection (TLS) to the region-specific relay server — for example, eu-relay.uipath.com.
4. The Relay Server validates the connection via OIDC and verifies the client configuration against the registered Relay Group, preventing a client from claiming endpoints it does not own.
5. When a UiPath service needs to call an on-premises endpoint, it retrieves the Relay URL from the Relay API and obtains a relay-scoped token from UiPath Identity.
6. The service calls the Relay URL. The relay infrastructure validates the token and the consuming tenant's authorization before forwarding the request through the tunnel.
7. The Relay client terminates the inbound tunnel connection and re-initiates an HTTP or HTTPS connection to the on-premises endpoint over the local network.

Hinweis:

For best throughput, deploy the Relay client in the same geographic region as your cloud tenant. Traffic follows the path UiPath Cloud → relay server → relay node → on-premises service, so cross-region tunnels add latency proportional to the round-trip time between the regions — for large-payload scenarios this difference is significant.

Hohe Verfügbarkeit (High Availability)

For production environments, deploy at least two Relay clients within the same Relay Group with identical network access and trust store configuration. Clients in a group share load via round-robin distribution and fail over automatically if one client becomes unavailable.

When multiple clients use proactive reconnect, they coordinate so that only one client drains at a time, keeping the group continuously available throughout each reconnect cycle.

Sicherheitsmodell

• Authentication. The Relay client authenticates to the cloud platform using OAuth 2.0 Client Credentials. The Relay Server validates each control connection via OIDC and verifies the client matches the registered Relay Group.
• Encryption at rest. Credentials stored on the Relay client machine are encrypted: AES-256-GCM on Linux, DPAPI on Windows.
• Encryption in transit. All traffic between the Relay client and the Relay Server is encrypted with TLS.
• Token scoping. UiPath services obtain a relay-scoped token before calling a Relay URL. The relay infrastructure validates this token and the consuming tenant's authorization before forwarding the request.

TLS and certificate trust

The Relay client terminates and re-initiates HTTP or HTTPS connections to on-premises targets. When the on-premises endpoint uses HTTPS, the OS trust store on the Relay client machine must trust the certificate authority (CA) that signed the on-premises endpoint's certificate.

If your endpoint uses a self-signed certificate or a private corporate CA, add the issuing CA to the Relay client machine's trust store before starting the relay. Failure to do so causes the Relay client to reject the connection to the internal target.