Provisioning an Automation Account

1. Start Locally

Firstly, we need to launch Locally which we can do from a terminal by running:

Once Locally has started, the Locally Dashboard will open automatically:

2. Create a Resource Group

Next we can create the Resource Group:

There's two things to note here:

1. The Azure CLI supports Automatic Configuration, meaning that it can automatically be configured to work against Locally just by prefixing commands with locally run.
2. Locally intentionally uses a different set of locations to Azure as a safety precaution, so that you can be confident you're deploying against Locally rather than regular Azure. You can also configure Locally to use the Azure locations too, but you'll want to be extra sure that you're prefixing commands with locally run when you do.

3. Create the Automation account

With the Resource Group in place, we can create the account:

{
  "note": "some fields skipped for brevity",

  "id": "/subscriptions/307d8f52-9719-460e-9f85-aa408e28ee55/resourceGroups/sample-resources/providers/Microsoft.Automation/automationAccounts/sample-automation",
  "location": "berlin",
  "name": "sample-automation",
  "sku": {
    "name": "Basic"
  },
  "state": "Ok",
  "type": "Microsoft.Automation/automationAccounts"
}

The Azure CLI warns that the az automation commands are experimental. That warning comes from the Azure CLI itself, and you'll see it against Azure too.

4. Add a runbook

First we'll write a small PowerShell script to use as the runbook:

Which gives us a hello.ps1 containing:

Write-Output "Hello from Locally"

Then create the runbook in the account:

{
  "name": "hello",
  "state": "New",
  "type": "PowerShell"
}

A new runbook is empty, so next we upload the script as its draft. The Azure CLI has az automation runbook replace-content for this, but it currently fails with name 'response' is not defined - against Azure as well as Locally - so we'll call the API directly with az rest:

az rest fills in {subscriptionId} for us. Now we can publish the draft:

And check it's been published:

{
  "name": "hello",
  "state": "Published",
  "type": "PowerShell"
}

The published content is our script:

Write-Output "Hello from Locally"

5. Add a schedule

Runbooks usually run on a schedule, so let's create a daily one:

{
  "enabled": true,
  "frequency": "Day",
  "interval": 1,
  "name": "nightly",
  "nextRun": "2030-01-01T02:00:00+00:00"
}

6. Start the runbook

We can start the runbook, which creates a job:

{
  "exception": "Locally does not execute runbooks, so this job was recorded but the runbook did not run.",
  "runbook": "hello",
  "status": "Failed"
}

As mentioned at the start, Locally doesn't run runbooks yet, so the job fails and says so rather than pretending to succeed. The job is still recorded:

Runbook    Status
---------  --------
hello      Failed

We can see the Automation account in the Locally Dashboard too:

7. Tidy up

Finally, we can tidy up. To remove the Resource Group and everything within it:

Doing this with other tooling

Whilst this guide used the Azure CLI, Automation works the same way through any of the tooling that Locally supports - Microsoft.Automation/automationAccounts and its runbooks and schedules in HashiCorp Terraform or OpenTofu, Pulumi, Bicep or an ARM Template all provision against Locally in the same way, with only the location changed.

Next steps

Since runbooks don't run in Locally yet, a Function App with a timer trigger is the way to run scheduled code today - the Function App Emulator shows each invocation.

Should you encounter any issues, please take a look at the troubleshooting section.