- Getting started
- Data security and compliance
- Organizations
- Authentication and security
- Licensing
- About licensing
- Unified Pricing: Licensing plan framework
- Activating your Enterprise license
- Migrate from Test Suite to Test Cloud
- License migration
- Assigning licenses to tenants
- Assigning user licenses
- Deallocating user licenses
- Monitoring license allocation
- License overallocation
- Licensing notifications
- User license management
- Tenants and services
- Accounts and roles
- AI Trust Layer
- External applications
- Notifications
- Logging
- Data Export
- Testing in your organization
- Troubleshooting
- Migrating to Test Cloud
Private Link, Relay, VPN Gateway, IP restriction, and credential store proxies for Test Cloud, and how authorization layers on each option.
Test Cloud runs on the UiPath cloud platform and requires secure HTTPS with TLS 1.2 or higher for inbound communications, the same baseline as other UiPath cloud platforms. Encryption describes encryption at rest and service-specific encryption options. Customers with stricter network isolation, firewall, private-resource access, or compliance requirements have additional connectivity options that limit traffic paths, narrow the networks allowed to reach UiPath, and keep credential retrieval aligned with customer vault policy.
This page brings these options together in one place and links to the detailed documentation for each:
- Baseline — HTTPS with TLS 1.2 or higher remains required for inbound communications.
- Defense in depth — private paths, outbound-only tunnels, allowlists, and IP restriction reduce exposure.
- Secret control — credential stores and proxies keep vault ownership with the customer.
Connectivity options
Each option addresses a different traffic direction and trust boundary. The following table summarizes what each one does from a customer-facing perspective.
| Option | Customer-facing use |
|---|---|
| Private Link | Routes traffic from a customer Azure VNet to Automation Cloud through Azure Private Link, keeping the connection to cloud.uipath.com on a private path. Some subdomains and features are not supported. |
| Relay | Lets UiPath cloud services reach customer-hosted HTTP or HTTPS endpoints that are not exposed to the public internet, through a client that opens outbound-only connectivity over port 443. |
| VPN Gateway | Creates site-to-site private connectivity between Automation Cloud robot networks and the customer network, for VM-based and serverless Cloud Robots that need private access to internal resources. |
| IP restriction | Limits access to the organization to trusted public IPv4 or IPv6 CIDR ranges, for users, API clients, and robots consuming UiPath APIs. |
| Outbound IP allowlisting | Applies when UiPath services initiate connections to customer systems. Customers allowlist the published UiPath outbound IP ranges by region in their firewalls. |
Customer credential store connectivity
Customer credential stores let Orchestrator retrieve robot credentials and credential assets from external vaults, such as Azure Key Vault, CyberArk, HashiCorp Vault, AWS Secrets Manager, BeyondTrust, or Google Secret Manager. Two proxy models are available:
- Connected proxy, managed by Orchestrator — Orchestrator retrieves credentials from the proxy and passes them to the robot.
- Disconnected proxy, managed by the proxy service — credentials are retrieved directly from the proxy without passing through Orchestrator.
Integration Service connections can reference Orchestrator credential assets for secret connection fields, such as passwords, API keys, and client secrets. Integration Service resolves the secret through Orchestrator from the linked external vault and does not store the secret value in its own database. Both proxy models are supported.
Why these options add security beyond HTTPS/TLS
TLS 1.2 or higher encrypts data in transit and remains required. These options add defense in depth by reducing exposure, narrowing trusted networks, and keeping credential retrieval under customer control:
- Private Link reduces public internet exposure for supported customer-to-UiPath traffic.
- Relay avoids inbound firewall openings by using outbound-only tunnels from the customer network.
- VPN Gateway enables private IP routing for Cloud Robots that need internal network access.
- IP restriction and outbound IP allowlisting limit which networks can reach UiPath or customer systems.
- Credential store proxies reduce exposure of secrets and support customer-controlled secret management.
Connectivity direction guide
The right option also depends on which direction traffic travels and where the target system lives.
| Traffic direction | Primary option | Use when |
|---|---|---|
| Customer, user, or robot to UiPath | HTTPS/TLS; Private Link where supported; IP restriction | Access originates from customer networks, browsers, robots, or API clients. |
| UiPath service to customer public endpoint | Outbound IP allowlisting | The customer system is public but should only trust UiPath-originated traffic. |
| UiPath service to customer private HTTP/HTTPS endpoint | Relay | Private HTTP/HTTPS APIs need to stay reachable without opening inbound firewall ports. |
| Cloud Robots to customer private network resources | VPN Gateway or Relay | VPN Gateway for private network routing; Relay for HTTP/HTTPS endpoint calls that fit its access pattern. |
| Robots or Integration Service retrieving secrets | Credential stores with connected or disconnected proxy | Secrets are stored in customer-controlled vaults. |
| Agents calling private tools or systems | Integration Service shared connections with Relay for private endpoints | Agent tools call private APIs through governed Integration Service connections. |
| Agents requiring human review | Action Center / Action apps | Approval, validation, exception handling, or missing information is needed. |
Product connectivity matrix
The following table maps each UiPath SaaS product or capability to its typical connectivity option.
| UiPath SaaS product or capability | Typical connectivity option | When to use it |
|---|---|---|
| Test Cloud portal and admin | HTTPS/TLS; Private Link where supported; IP restriction | Private Link for private Azure-originated access; IP restriction when only trusted public IP ranges should access the organization. |
| Orchestrator | HTTPS/TLS; IP restriction; credential stores; outbound IP allowlisting | Credential stores and proxies for customer-controlled secret retrieval alongside baseline API and robot communication. |
| Integration Service | Public connections; Relay for private HTTP/HTTPS; credential assets for secret fields | Relay when the endpoint is private; credential assets when secret values must resolve from Orchestrator and an external vault. |
| API Workflows and Agentic Processes | Integration Service with Relay for private APIs | On-premises or private APIs must be called without changing the network perimeter. |
| Automation Cloud Robots - Serverless | Relay for on-premises HTTP APIs; VPN Gateway for private network access; outbound IP allowlisting | Relay for HTTP/HTTPS endpoints; VPN Gateway when the robot needs private routing to internal resources. |
| Automation Cloud Robots - VM | VPN Gateway; outbound IP allowlisting | VM-based Cloud Robots need private access to resources behind a customer firewall. |
| Apps and Action Center | HTTPS/TLS; IP restriction; downstream option depends on connected automation | Standard access controls apply to the user review experience; downstream systems use the relevant automation or connection path. |
| Agents | Governed Integration Service activities and tools; Relay through shared connections for private systems | Tools, automations, models, or downstream systems are private or firewall-restricted. Conversational agents require shared connections; personal connections are not supported. |
| Agent human-in-the-loop escalations | Action Center / Action apps | Escalation, approval, validation, exception handling, or missing information. |
| AI Trust Layer / bring your own LLM scenarios | Relay for private endpoints; outbound IP allowlisting for public endpoints | Relay when the LLM endpoint is on-premises or in a private network; allowlisting when it is public but restricted. |
| Customer credential stores and credential assets | Connected or disconnected credential proxy; Orchestrator credential assets | Connected proxy when Orchestrator should broker retrieval; disconnected proxy when credentials must come directly from the customer-managed proxy service. |
| Test Manager | HTTPS/TLS; IP restriction; outbound IP allowlisting for external integrations | Same organization access controls, with allowlisting for integrations that call customer-controlled systems. |
| Insights, IXP, Document Understanding, Process Mining, Task Mining, Automation Ops, Studio Web | HTTPS/TLS; IP restriction where organization access is the concern; product-specific outbound allowlisting | Baseline SaaS access, with the firewall documentation for current outbound ranges when a service initiates traffic to customer systems. |
Recommended selection guidance
The following guidance summarizes when to reach for each option:
- Private Link, for private customer-to-UiPath access from Azure.
- Relay, when UiPath cloud services need to call private HTTP/HTTPS customer endpoints without opening inbound firewall ports.
- VPN Gateway, when Cloud Robots need private network routing to internal resources.
- IP restriction, when only approved customer public IP ranges should reach UiPath.
- Outbound IP allowlisting, when customer systems need to trust UiPath-originated traffic.
- Connected credential proxy, when Orchestrator should broker credential retrieval.
- Disconnected credential proxy, when credentials must come directly from the customer-managed proxy service rather than through Orchestrator.
HTTPS/TLS remains the baseline for Test Cloud connectivity. Private Link, Relay, VPN Gateway, IP restriction, outbound IP allowlisting, and credential store proxies add network isolation, access control, and customer-controlled secret handling. The right option depends on traffic direction, resource location, and whether the target system is public, private, firewall-restricted, or secret-backed.
Authorization layers
Private Link, Relay, and VPN Gateway control how traffic reaches UiPath or customer-hosted systems. None of them replaces application authorization. Authorization is layered instead: the network path must be allowed, the UiPath identity or application must be permitted, and the destination system still authorizes the request with its own controls.
| Connectivity option | Network authorization | UiPath authorization | Customer system authorization |
|---|---|---|---|
| Private Link | Approved private endpoint, private DNS, and customer VNet or firewall rules determine reachability to cloud.uipath.com. | Users, robots, and API clients still authenticate with UiPath Identity. Organization, tenant, folder, license, role, and API-scope permissions still apply. | Not applicable — this pattern is primarily customer-to-UiPath access. |
| Relay | A customer-side Relay component opens outbound connectivity; no inbound firewall rule is required. | UiPath governs who can configure and use the Relay-backed connection. Connection credentials or credential assets authorize the outbound call. | The target API still enforces its own authentication, such as OAuth, an API key, basic auth, mTLS, or a service account. |
| VPN Gateway | The IPsec/IKE site-to-site tunnel is authorized by peer configuration, a pre-shared key, routing, and firewall policy. | The cloud robot authenticates to Orchestrator to receive jobs, under UiPath roles and folder permissions. The tunnel itself grants no application permissions. | Internal resources authorize the robot with their normal mechanism, such as domain identity, database credentials, API tokens, or application roles. |
Private Link
Private Link is primarily a customer-to-UiPath access pattern. It changes the route to Automation Cloud services by resolving cloud.uipath.com to a private endpoint in the customer Azure VNet, then carrying HTTPS traffic to the UiPath regional gateway over Azure Private Link. Network reachability is authorized by Azure private endpoint approval, private DNS, VNet routing, security groups, and customer firewall policy.
UiPath authentication is unchanged: users, robots, and API clients still sign in through UiPath Identity or the configured identity provider and receive normal tokens. UiPath authorization is then enforced through organization, tenant, folder, role, license, and OAuth scope checks — a private endpoint cannot grant access to a service, tenant, folder, or API scope by itself. For API clients, a valid bearer token with the right scopes and permissions is still required.
Operationally, DNS and failover planning matter: if multiple private endpoints are used for resiliency, the customer controls which endpoint cloud.uipath.com resolves to.
Relay
Relay is primarily a UiPath-to-customer-private-endpoint pattern, useful when Integration Service, API Workflows, or agentic processes must call an internal HTTP/HTTPS API that is not exposed to the public internet. Network reachability is authorized by the registered Relay group and endpoint configuration; the customer-side connectivity is outbound, so no inbound internet-facing firewall opening is needed.
UiPath governs which administrators can configure the Relay-backed connection and which automations can use it. The Relay path does not automatically authorize the business action at the target — the target system still validates the connection's credentials, such as OAuth tokens, API keys, basic credentials, mTLS certificates, or service-account permissions. Secrets should be stored and governed through Integration Service connection settings or Orchestrator credential assets rather than embedded in workflows.
A common review question is whether the Relay connection is scoped narrowly enough — dedicated endpoints, dedicated service accounts, least-privilege permissions, and target-side logging where possible.
VPN Gateway
VPN Gateway is primarily a cloud-robot-to-customer-network pattern, creating site-to-site private routing so VM or serverless Cloud Robots can reach internal resources behind the customer firewall. Tunnel authorization is handled at the network layer, through the customer VPN device, the UiPath gateway public IP, IPsec/IKE settings, a pre-shared key, optional BGP peer settings, route exchange or static routes, and firewall policy.
The VPN does not perform UiPath application authorization. Robots still authenticate to Orchestrator, receive jobs based on folder and machine-template configuration, and execute under the permissions assigned to the automation. Internal systems still authorize the robot's access independently, depending on the target — for example, domain authentication, database credentials, API tokens, SSH keys, application roles, or a managed service account.
Source identity at the network layer comes from robot CIDRs, not the VPN gateway CIDR. Firewalls and return routes should allow the relevant Cloud Robot VM pool CIDRs or serverless robot CIDR. Because VPN Gateway does not perform NAT, address spaces must be non-overlapping and routable in both directions.
Review considerations
A connectivity review typically covers:
- Which layer is being approved — private network path, UiPath identity and role access, API scopes, or target-system permissions.
- Whether the connectivity option broadens application permissions beyond what the identity, token, role, and target credentials allow.
- Least-privilege service accounts, with separate credentials for production, test, and administrative flows.
- Logging on both sides — UiPath audit and job history for platform activity, plus firewall, Relay, VPN, and target-system logs for network and resource access.
- DNS, routing, CIDR, failover, and credential-rotation ownership, documented before production rollout.