Runner network and egress requirements

A CloudRadial AutomationAI runner is outbound-only: it has no public ingress and connects out to the control plane on its own schedule. On a standard virtual network its egress works out of the box, and you only need to act in a locked-down environment. This article lists the outbound targets to allow, and it is for the technician operating a runner.

We'll cover three things:

1. Understanding the outbound-only posture
2. Allow-listing the runner's outbound targets, for locked-down networks only
3. Allowing your workspace Outbound IP on your own systems

Step 1: Understanding the Outbound-Only Posture

Why are we doing this? Knowing that the runner only makes outbound calls tells you whether you need to change anything. On a standard network you do not.

The runner exposes no inbound endpoint. There is no public ingress, no broker, and no shared-access tokens. Its Function Apps poll the control plane over outbound HTTPS, and AI traffic stays on the private Foundry endpoint inside the runner's virtual network by default. On a standard VNet the required egress is already allowed, so the allow-list in Step 2 matters only where outbound traffic is restricted.

Step 2: Allow-Listing the Runner's Outbound Targets

Why are we doing this? In a locked-down environment the runner cannot reach the control plane or download its code unless you permit these outbound HTTPS destinations. Skip this step on a standard network.

In a locked-down environment, allow outbound HTTPS to:

• The control plane, your regional CloudRadial control-plane URL (automationai*.cloudradial.com), which the runner polls for work
• The runner package store, crautopkg<region>.blob.core.windows.net, the CloudRadial package store the runner downloads its code package from (anonymous blob read, no token needed)
• OpenAI, only in OpenAI mode, api.openai.com (or your endpoint override). This is required only when the runner's AI provider is set to OpenAI; the default Foundry provider keeps all AI traffic on the private endpoint with no internet egress

Note: If your egress controls require a different package-store URL, CloudRadial support can provide a mirrored one to use in place of the default. For the AI-provider choice, see Choosing the runner AI provider (Foundry or OpenAI).

Step 3: Allowing Your Workspace Outbound IP on Your Own Systems

Why are we doing this? When your workflows reach out to your systems, they come from a single Outbound IP. If those systems restrict access by IP, they will block AutomationAI until you allow it.

Your workspace has an Outbound IP shown under Settings > Overview as the Outbound IP allowlist. This is the address AutomationAI uses when it reaches out to your systems from your workflows, so if those systems restrict access by IP, allow this address on their firewalls.

This is a separate concern from the runner's outbound egress above: the runner allow-list governs what the runner can call, while the Outbound IP is what your own systems should permit so AutomationAI can reach them.

Note: The Outbound IP appears only when one is configured for your workspace.

With egress handled, you are ready to choose how the runner will be hosted. Next: Runner plans: Premium vs. Flex Consumption.

If you are still having trouble, we're here to help! Submit a ticket here for assistance, and don't forget to check our status page to ensure there are no outages in your area.