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, how scale-down and poll staggering behave, and how your plan sets the ceiling. It is for the technician operating a runner.

Before you start, run the installer from the same PowerShell 7 environment you used to install the runner, signed in with Az PowerShell. If PowerShell 7 or the Az module is not set up, see Runner prerequisites and Azure requirements first.

In this article:

• What a runner pool is
• Scaling up or down
• Plan limits and over-limit behavior
• 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.

Important -> Use the upgrade script only for version changes. It never changes the pool size.

Plan Limits and Over-Limit Behavior

How many runners you can register, and how many instances each runner can have, is set by your plan edition:

• Trial and Starter: 1 runner, 1 instance per runner.
• Professional: 2 runners, up to 3 instances per runner.
• Enterprise: 20 runners, up to 3 instances per runner.

The Runners page shows your plan's current standing, and the Register runner action and instance-count inputs are bounded by these limits. If a plan change ever leaves you above the limit (for example, after a downgrade), the runners you already have keep reporting as healthy, but the control plane stops handing them new work until you are back within the limit. Work already in progress finishes normally.

Recovery is automatic and needs no support request: scale a runner down, remove a runner, or move to a higher edition, and new work resumes on the next poll. To bring a pool back under its per-runner instance ceiling, re-run the installer with an -InstanceCount at or below the limit.

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.

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