Scaling runner instances

A CloudRadial AutomationAI runner is one identity backed by any number of instances that share the work. This article explains how to scale a runner up or down by re-running the installer with an instance count, what the instances share, and how scale-down and poll staggering behave. It is for the technician operating a runner.

• What a Runner Pool Is
• Scaling Up or Down
• Shared Identity and Secret
• How Scale-Down Behaves
• Poll Staggering

What a Runner Pool Is

A runner is one identity backed by N instances. With -InstanceCount 3 the installer deploys instances named <name>1, <name>2, and <name>3. Each instance gets its own Function Apps and hosting plans, while the shared resources — virtual network, Key Vault, storage, and Foundry — are created once and reused. Any instance picks up the next pending job, so the pool spreads work across instances. The index is always suffixed, so a single-instance pool is <name>1.

Scaling Up or Down

-InstanceCount is the single source of truth for pool size. To change it, re-run the same installer with a new count:

./Install-AutomationsRunner.ps1 -InstanceCount 5

• Scale up deploys the missing higher-index instances; existing instances and the shared resources are re-applied idempotently
• Scale down removes the instances above the new count

Instances deploy sequentially, so the time the install takes scales with the count. The Deploy / scale action on the Runners page records the count and downloads the package for you. Use the upgrade script only for version changes — it never changes the pool size.

Shared Identity and Secret

All instances in a pool share the one runner identity and the one runner secret. The secret is stored once in the shared Key Vault, and every instance reads that single entry. This is why scaling does not require new registration or a new secret: you are adding execution capacity to the same registered runner.

How Scale-Down Behaves

When the new count is lower than what is running, the installer removes the extra instances in a controlled sequence:

1. It stops the extra instances so they stop polling immediately
2. It waits about five minutes, with a visible countdown, for the stopped instances to fall out of the control plane's health window
3. It asks you to confirm, then deletes the extra instances' Function Apps and plans

Type yes at the prompt to proceed, or pass -Force to skip the confirmation in an unattended run. If you cancel, the stopped instances are left in place — you can start them again or re-run to remove them.

Poll Staggering

Each instance's poll timer is phase-staggered across the pool so the instances do not all check in at the same instant. Instance i fires at an offset of (i-1) * PollingIntervalSeconds / InstanceCount within each interval. With a 60-second interval and two instances, instance 1 polls at :00 and instance 2 at :30; with three instances, at :00, :20, and :40. The stagger is baked into each instance's schedule at deploy time, so it costs nothing at runtime. Because the schedule resolves to whole seconds, a pool whose interval divided by its count rounds below one second cannot fully separate.