CloudRadial AutomationAI publishes runner code as immutable, versioned packages. How a runner moves to a newer version depends on its version: a runner on version 2.0 or later maintains itself, and one on an earlier version is upgraded with a script you download from the Runners page. This article covers both paths, the one-time step that turns a script-managed runner into a self-updating one, and the controls you have over when an update happens. It is for the technician operating a runner.
If your runner is on version 2.0 or later, you do not run an upgrade script. Setting the target version is the upgrade; the runner applies it and verifies itself.
In this article:
- Self-updating runners
- Turning on self-updating for an existing runner
- Upgrading a runner on an earlier version
- How the upgrade works per plan
- How long an update takes
- Features that require a minimum version
Self-Updating Runners
A runner deployed at version 2.0 or later carries a small supervisor application alongside its script and agent runners. Every couple of minutes the supervisor asks the control plane what this runner should be running — which version, and how many instances — and reconciles the runner to match.
- It updates one application at a time, so the rest of the runner keeps taking work.
- It lets an instance finish any step already in flight before touching it.
- It verifies that each application actually checks in on the new version before moving to the next one.
- If an application does not come back on the new version, the supervisor rolls it back and halts the runner, leaving it on the version that works.
The Runners page shows a self-updating runner as self-managed, and offers no upgrade download for it, because there is nothing for you to run. If a runner is halted or its supervisor has stopped checking in, the page says so and offers the repair path instead.
Controlling When Updates Happen
You are not obliged to take every version the moment it ships. From the runner’s detail page you can:
- Pin the runner to a specific version, so it stays there until you unpin it
- Set the update policy to manual, so the runner only moves when you ask it to
- Use Update now when the runner is pinned, set to manual, or outside its update window
- Clear a halt after you have addressed whatever made an update fail
These actions require the Owner or Admin Role.
Turning On Self-Updating for an Existing Runner
A runner installed on an earlier version has no supervisor, so it cannot update itself yet. Bringing it onto the self-updating path is a one-time step: run the installer once more against the same resource group, using the same runner.
- Script installer: re-run
Install-AutomationsRunner.ps1(orDeploy-Runner.ps1) as you did for the original install. - Azure Marketplace: re-run the offer into the same resource group, leaving the runner secret blank.
After that one run, the runner maintains itself and you will not need the installer again for version changes.
Upgrading a Runner on an Earlier Version
Until a runner has a supervisor, you move it with an upgrade package downloaded from the Runners page. The package is generated for that one runner and targets a specific version. Run it from the same PowerShell 7 environment you used to install the runner, signed in with Az PowerShell; you need the Az.Accounts, Az.Resources, and Az.Websites modules. If PowerShell 7 or the Az module is not set up, see Runner prerequisites and Azure requirements first.
The upgrade package contains Update-AutomationsRunner.ps1 and an UPGRADE.md. It is credential-free and provisions nothing new. It only moves your runner’s Function Apps to the target version’s package, so your runner identity, secret, Key Vault, and networking are untouched.
Connect-AzAccount
./Update-AutomationsRunner.ps1 -SubscriptionId <your-subscription-guid>-SubscriptionId is optional. Omit it to choose from a numbered list of the subscriptions your login can access. You can also add:
-
-WhatIfto preview the changes first. -
-TenantId <tenant-guid>if the subscription is in a non-default Entra tenant, or you hit a multi-factor prompt. -
-ResourceGroup <name>to scope the search.
Every instance of a runner carries the same identity tag, so one upgrade run sweeps all of them. The upgrade only moves the version and never changes the pool size. Re-running it is safe: an application already on the target version is simply re-applied.
How the Upgrade Works per Plan
Whether it is the supervisor or the script doing the work, each application is upgraded the way its hosting plan requires:
- Premium: the app is repointed at the target package, its runtime stack is reconciled, and it is restarted.
- Flex Consumption: Flex has no run-from-package, so the package is pushed to the app. Because the runner sits with no public access, its deploy endpoint is opened transiently for the push and re-locked afterward, even if the push fails.
The agent flavor is always on Flex Consumption and is upgraded the same way as the script runners.
How Long an Update Takes
A self-updating runner works through one application per cycle and confirms each one before continuing, so a full update is deliberately unhurried. Budget roughly four minutes per application, and expect the occasional one to take longer on a cold start. A single-instance runner is usually done in about twenty minutes; a three-instance runner can take well over an hour, and longer still if its instances are busy, because each one finishes its in-flight work first. A slow rollout is the design, not a stall — the Runners page shows which applications have moved.
Features That Require a Minimum Version
Most AutomationAI features work on any supported runner version, but some require a floor. Company-scoped credentials need runner 1.7.0 or later; a company-scoped step will not run on an older runner, and deploying a company-scoped workflow to an out-of-date runner is blocked. Self-updating and scaling from the Runners page need runner 2.0 or later.
If a runner is below the version a feature needs, the Runners page flags it as out of date.
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.
Comments
0 comments
Please sign in to leave a comment.