A runner is an Azure Functions app deployed in your own Azure subscription. It continuously polls the AutomationAI control plane, retrieves pending work, executes it, and reports results back. All communication is outbound from the runner, so the control plane cannot initiate direct connections to it. This article covers registering a runner, saving the one-time secrets, choosing how to deploy it, the health dashboard, rotating a secret, and revoking. It is for the technician setting up a runner.
We'll follow six main steps:
- Registering a runner
- Saving the runner secret
- Choosing a deployment method
- Monitoring runners on the health dashboard
- Rotating a runner secret
- Revoking a runner
Step 1: Registering a Runner
Why are we doing this? Registration creates the runner's credentials in AutomationAI so the control plane can recognize it. It does not deploy the Azure resources; that is a separate install step.
Open Runners and select Register runner. You will need to provide:
- Runner name, must use lowercase letters, digits, and single hyphens; start with a letter; be 2 to 32 characters long; and be unique among your runners
- Instances, the number of runner copies to deploy (adjustable later)
Step 2: Saving the Runner Secret
Why are we doing this? The secret is how the runner proves its identity to the control plane, and you only get one chance to capture it.
REQUIRED: The runner secret displays only once at registration and cannot be retrieved afterward. When the runner is registered, a panel opens with the secret in a Runner secret — shown once field. Use the copy button on that field, then paste it into your password manager. It is not stored by AutomationAI; only a hash is kept. If it is lost, you can rotate it rather than registering a new runner — see Step 5.
A runner at version 2.0 or later is issued a second one-time value, the supervisor secret, used only by the supervisor that keeps the runner up to date. Copy and store it the same way. It is separate from the runner secret on purpose: every runner application holds the runner secret, so the supervisor needs a credential of its own that the applications running your scripts do not have.
Keep the panel open — the deployment method you pick in Step 3 needs these same values.
Step 3: Choosing a Deployment Method
Why are we doing this? The deployment method decides how the runner's Azure resources get created, and the panel shows only the settings that method needs.
Under Deployment method, pick one:
-
Script installer, download a setup package and run
Install-AutomationsRunner.ps1from PowerShell 7. Use this when you want multi-instance pools or full control over the deployment parameters - Azure Marketplace, deploy from the Azure portal with a guided wizard and no local script. Deploys a single instance
Either method needs the right role on your Azure subscription, and the script installer also needs PowerShell 7, the Azure CLI, and the Bicep CLI on the machine you run it from. See Runner prerequisites and Azure requirements before you download, and check the machine against it.
If you choose Script installer, also choose a hosting plan before downloading the package:
- Flex Consumption, scales to zero, pay-per-use, with cold-start latency after idle periods
- Premium (EP1), always warm with no cold starts but higher monthly cost
If you choose Azure Marketplace, the panel shows the region to select in the wizard plus copy buttons for your tenant ID and runner identity ID, and a button that opens the offer in the Azure portal. You choose the hosting plan and AI provider inside the wizard instead.
You can modify the instance count later via the Deploy/scale option.
Note: For a deeper comparison of the two hosting plans, see Runner plans: Premium vs. Flex Consumption. For the Marketplace path end to end, see Installing a runner in your Azure subscription.
Step 4: Monitoring Runners on the Health Dashboard
Why are we doing this? The dashboard tells you at a glance whether a runner is healthy and receiving work.
The Runners list displays each runner's status. Runners offline for five minutes are marked as unavailable. The dashboard shows execution stats, per-instance liveness, and available actions.
Step 5: Rotating a Runner Secret
Why are we doing this? Both one-time secrets can now be replaced without registering a new runner — if one was never captured, or you simply want to roll it.
From the runner’s detail page, choose the rotate action for the credential you need. AutomationAI issues a new value and shows it once, exactly as at registration, and the old value stops working. Copy the new value and apply it to the runner: store it in the runner’s Key Vault, then stop each affected Function App, wait at least five minutes so the cached value clears, and start it again — a restart alone can leave a Flex Consumption app signing with the old secret, and it will keep returning 401. Or re-run the installer with the new value. Rotating requires the Owner or Admin Role.
Important -> The runner cannot check in between the rotation and the moment the new value reaches it, so do the two together.
Step 6: Revoking a Runner
Why are we doing this? Revoking permanently deactivates a runner's credentials, for example when you are decommissioning it.
Important -> Revoking cannot be undone. To run again you register a new runner.
The runner stops receiving work immediately, and existing deployments fail. A revoked runner's name becomes available for reuse.
With the runner registered and the secret saved, you are ready to install it in Azure. Next: Installing a runner in your Azure subscription.
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
Article is closed for comments.