Logic Apps Automation is in preview. This post explains how an automation app gets created in a managed environment, what that creates underneath, and how its versions and scaling work. I created a project and two apps in UK South to check this against Azure's resources.
The short version
- You create a project, then add apps to it. Each app becomes its own Azure Container App.
- Every change to an app's revision creates a new version. The active version takes the traffic.
- Each app has its own scale settings, so each scales on its own rules. The docs for Container Apps describe this design. I haven't measured it on Automation yet.
- The runtime is a tagged image on Microsoft Container Registry. You choose the tag in the portal, or point at a custom image.
How you create an app
Microsoft's project quickstart covers creating a project, and the application quickstart covers creating an app from the Apps page.
-
Create a project. Azure creates a resource of type
Microsoft.Logic/automationProjectsin the resource group you choose. In my case that wasla-auto-rgin UK South. -
Create an app in the project. The app is a
Microsoft.Logic/automationProjects/applicationsresource. It takes about 1.5 minutes to go fromProvisioningtoSucceeded, which matches the docs' "a minute or two". - Add workflows. Adding a workflow to the app changes it, so it creates a new version.
The project resource has no plan or networking properties of its own. The docs say a project has "its own compute, networking, security, and governance," but they don't say where that compute is.
The portal and the docs use different names for the same thing. The docs say "project", while the portal's breadcrumb reads Environment > App > Workflow. The Azure portal shows the project as Automation Environment, and its blade lists the apps. The Azure portal also gives it Properties, Locks, Alerts, Metrics and Logs, so you can monitor and lock it like any other Azure resource.
Each app becomes a Container App
The app's appResourceId points to a Container App, not to a Standard site on an App Service Plan:
Microsoft.App/containerapps/autoapp-f9e90f8b1cb2 (hello-world)
Microsoft.App/containerapps/autoapp-234077aeb7bd (my2-app)
resource group: la-auto-demo-rg-625cf32
subscription: 30a69ef7… (not the project's subscription)
Each app gets its own Container App, with its own name and managed identity. Both container apps are in the same resource group, la-auto-demo-rg-625cf32, which is in a subscription other than the project's. I read this from the two resource IDs. I can't open that subscription to see what else is in it.
The overview compares an application to a Standard logic app.
Marczak compares the visual designers of Automation and Standard, and finds the UI different but the options mostly the same. His hosting comparison describes Automation as Microsoft-managed hosting capacity, against customer-provisioned capacity for Standard. InfoQ's coverage says each project gets an isolated compute boundary, and presents that as a current feature.
Versions are revisions
Each app's Container App keeps its versions as revisions. A change to a revision's scale rules or image creates a new revision, and the old revision stays in place, so you can roll back by moving traffic (Container Apps scaling docs). Not every setting creates a revision. The revision change types page lists which ones do.
In the app's Configuration tab, the portal hides zero-replica revisions by default. Select Showing all revisions to see them all. hello-world has 14 revisions, and the active one is autoapp-f9e90f8b1cb2--0000013.
The first revision has a random suffix, cdkde5s. The later ones are numbered from 0000001, and every one uses the stable04 image.
Each app has its own scale settings
The Configuration tab sets each app's scale limits and timing:
| Setting | Value |
|---|---|
| Minimum replicas | 0 |
| Maximum replicas | 10 |
| Cooldown period | 300 seconds |
| Polling interval | 30 seconds |
In Container Apps, scale rules are set per revision, so each app's rules apply only to its own revisions. Each app here has its own Container App, so it should scale independently. Microsoft's comparison page says Automation's compute "scales to zero", and these settings are what control that.
I tested the scaling with 15 parallel requests to each app, one app at a time:
-
hello-world(agent workflow): all 15 returned 200, taking 75 to 102 seconds each. Its replicas went from 2/2 to 9/9, out of a maximum of 10. -
my2-app(a 9-second workflow): all 15 returned 200 in about 9 seconds each. Its replicas stayed at 2/2.
Runtime version
The app's Configuration tab lists the runtime versions. Each one is a tagged image on Microsoft Container Registry under azurelogicapps/otto-base:
| Version | Image | Status |
|---|---|---|
stable04 |
mcr.microsoft.com/azurelogicapps/otto-base:stable04 |
Current |
1.211.3563.1 |
mcr.microsoft.com/azurelogicapps/otto-base:1.211.3563.1 |
Available |
1.211.3557.2 |
mcr.microsoft.com/azurelogicapps/otto-base:1.211.3557.2 |
Available |
1.211.3541.4 |
mcr.microsoft.com/azurelogicapps/otto-base:1.211.3541.4 |
Available |
| Custom image | Any full registry/repository:tag reference |
Available |
The registry also has stable05, latest and validation, which the portal doesn't list. stable05 is newer than stable04. I haven't tested those three. The portal doesn't check custom images, so confirm the tag exists on MCR first.
A quick check that it runs
I built a small BODMAS agent in the automation designer, with an arithmeticmcp tool on gpt-5-mini. It solved (2 ^ 3) + 10 through the app's HTTP trigger, with HTTP 200 and the answer 18.
Most of the time goes to the model, not the tool. The two MCP tool calls took 835 ms and 494 ms. Each of the three iterations took 3.3 to 4.8 seconds. When you measure cold start, measure it apart from model latency.
Analytics: hello-world, last 24 hours
The app's Analytics tab reports these figures for the last 24 hours:
| Metric | Value |
|---|---|
| Total runs | 44, none in progress |
| Succeeded | 41 |
| Failed | 3 |
| Success rate | 93.2% |
| Run latency | p50 42.0 s, p95 1 min 31 s, p99 1 min 32 s |
The failures show as one spike on the Execution trends chart, at about 12 PM on the chart's time axis. The chart doesn't state its time zone, so I haven't matched the spike to a specific run. The 44 runs include my load tests and agent test runs, so these totals mix test and non-test traffic. The 60-run batch ran on a different app, so it isn't counted here. The summary cards may lag the chart, which shows more activity than the 44 runs suggest.
What the docs don't cover
The docs state that the compute is dedicated and scales to zero. They don't cover:
- Which Container Apps back each app, and the resource group and subscription they sit in.
- How long a cold start takes, and how long an idle app takes to scale to zero.
- Revisions, traffic splitting, and the fact that the portal hides zero-replica revisions.
- Runtime image names, tags and how to choose one.
- The managed identities on the project and app.
Top comments (0)