Add support to enable automatic scaling for App Service Environment #12305

ShilpiRach · 2025-10-23T09:42:28Z

Description

This PR adds support to enable automatic scaling for the Azure App Service Plan not enabled by default. This option is made available as it is considered a best practice to improve an app's performance and avoid cold start issues.

The change introduces an extension method WithAutomaticScaling for the AzureAppServiceEnvironment to enable automatic scaling. Customers can enable it with WithAutomaticScaling() or WithAutomaticScaling(true).

Testing

Tested deploying an Aspire project using aspire deploy and ensured that the properties related to automatic scaling are set correctly for the app service plan and app services.
Tested deploying an Aspire project WithAutomaticScaling(false) to ensure the properties related to PerSiteScaling are set correctly for the app service plan and app services.

Relevant properties for App Service Plan:

perSiteScaling - false for automatic scaling, true otherwise
elasticScaleEnabled - true for automatic scaling, false otherwise
maximumElasticWorkerCount - applicable only when elasticScaleEnabled is true

Relevant properties for App Service

numberOfWorkers - 1 for dashboard, max(30) for others
functionAppScaleLimit - 1 for dashboard, not set for others

Checklist

Is this feature complete?
- Yes. Ready to ship.
- No. Follow-up changes expected.
Are you including unit tests for the changes and scenario tests if relevant?
- Yes
- No
Did you add public API?
- Yes
  - If yes, did you have an API Review for it?
    - Yes
    - No
  - Did you add <remarks /> and <code /> elements on your triple slash comments?
    - Yes
    - No
- No
Does the change make any security assumptions or guarantees?
- Yes
  - If yes, have you done a threat model and had a security review?
    - Yes
    - No
- No
Does the change require an update in our Aspire docs?
- [] Yes
  - Link to aspire-docs issue (consider using one of the following templates):
- No

github-actions · 2025-10-23T09:42:42Z

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12305

Or

Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 12305"

… instance count to test

Copilot

Pull Request Overview

This PR enables automatic scaling for Azure App Service Plans by default to improve performance and avoid cold start issues. The change introduces a new WithAutomaticScaling extension method that allows customers to opt out if needed.

Key changes:

Automatic scaling is now enabled by default for App Service Plans
New WithAutomaticScaling(bool) extension method allows disabling the feature
App Service Plan configuration now includes elasticScaleEnabled, perSiteScaling, and maximumElasticWorkerCount properties
Dashboard configuration includes scale limit settings to ensure single-instance operation

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
AzureAppServiceEnvironmentExtensions.cs	Adds `WithAutomaticScaling` extension method and updates App Service Plan configuration logic
AzureAppServiceEnvironmentResource.cs	Adds `EnableAutomaticScaling` internal property with default value of true
AzureAppServiceEnvironmentUtility.cs	Updates dashboard site configuration to include scale limits
AzureAppServiceTests.cs	Adds test for disabling automatic scaling
*.verified.bicep	Updates snapshot tests to reflect new automatic scaling properties

Copilot · 2025-10-23T20:07:47Z

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs

+    /// <summary>
+    /// Configures whether automatic scaling should be enabled for the app services in Azure App Service environment.
+    /// </summary>
+    /// <param name="builder">The AzureAppServiceEnvironmentResource to configure.</param>
+    /// <param name="enable">Whether to enable automatic scaling. Default is true.</param>
+    /// <returns><see cref="IResourceBuilder{T}"/></returns>


The XML documentation is incomplete for a public API. According to Aspire's documentation standards, public APIs require comprehensive documentation including <remarks> and <example> sections. Add a <remarks> section explaining when/why to use this method and an <example> section showing practical usage with code.

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs

Copilot · 2025-10-23T20:07:48Z

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs

+    /// </summary>
+    /// <param name="builder">The AzureAppServiceEnvironmentResource to configure.</param>
+    /// <param name="enable">Whether to enable automatic scaling. Default is true.</param>
+    /// <returns><see cref="IResourceBuilder{T}"/></returns>


The return value documentation should follow the standard pattern for fluent APIs: "A reference to the <see cref="IResourceBuilder{T}"/> for chaining additional configuration."

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentResource.cs

mitchdenny · 2025-10-24T02:05:47Z

@ShilpiRach thanks for the contribution. I'm not sure that we'll take this change but I'm interested in @davidfowl and @maddymontaquila for input.

My issue with the change is really twofold:

It opts customers into a higher level of cost by default.
Applications are not always by default cluster tolerant.

Whilst we would want applications to be able to scale up, the app first needs to work correctly and its something that developers will need to assess on a case by case basis.

ShilpiRach · 2025-10-24T06:20:11Z

@mitchdenny - is your main concern about making automatic scaling the default option? If yes, I am fine with making it non-default.

Tagging @btardif to comment on your first comment about higher cost - who might have more data about this.

For the 2nd point, Applications deployed on cloud should usually work with scaling out. But you might be right about existing Aspire customers trying out App Service.

ShilpiRach · 2025-10-24T06:48:07Z

@mitchdenny - is your main concern about making automatic scaling the default option? If yes, I am fine with making it non-default.

Tagging @btardif to comment on your first comment about higher cost - who might have more data about this.

For the 2nd point, Applications deployed on cloud should usually work with scaling out. But you might be right about existing Aspire customers trying out App Service.

Made this change

mitchdenny · 2025-10-26T13:40:18Z

Thanks @ShilpiR. Just need to decide if we want to add this to the API surface now. We don't do these scaling options anywhere else.

tulikac · 2025-10-27T07:58:24Z

@mitchdenny - Autoscaling is a fundamental part of Azure App Service. What Shilpi is adding here is the platform detecting if the instance has too much load, it will scale out. Since Linux App Service does not have an autoheal feature, it basically means that if the instance becomes overloaded (because we are running atleast 6 containers, including Kudu which is a fairly heavyweight container), the app will just sit there in a bad state. And customers blame the platform rather than their app when this happens.

I cannot comment on what other platforms provide. However, most App Service customers are used to autoscale and its one of our top-used features. This is an optional enablement, and we will document that it has a cost. We are also working on enabling autoscale by default for all sites created from the portal.

ShilpiRach · 2025-10-27T08:36:58Z

@mitchdenny - For Azure Container Apps (ACA), consumption workload profile gets used in Aspire which automatically scales up, hence no separate option is needed.

Scale out in Azure App Service, unlike ACA, is not enabled by default (though as @tulikac mentioned, we are working on enabling automatic scaling by default on portal). It is, however, strongly encouraged as a best practice.

btardif · 2025-10-29T17:51:08Z

@mitchdenny just to underline what has already been said above:

Automatic scale is not opting folks into a higher cost by default, cost would only increase if/when load is present, this is the same as ACA where more load == more cost.
For your point on "applications are not default cluster tolerant" how is this handled in ACA where scale out is automatic based on load (consumption plan) we are no different in that sense, an app that works in ACA would work the same on App Service (or break on both)
if both points above make sense, then this should be OBD, if we want to be cautious, I'm ok with this being an optional feature but in either case we shouldn't be blocking the merge.

Had a separate conversation with @davidfowl where I think he understands the need to have potentially different configs applied if this is the first time something is being executed, and resources are being created vs N time were you would want to omit most of the config so that you don't scale down an app that has been scaled out (either manually, through rules, or automatic scaling) due to existing load.

CC: @tulikac @ShilpiRach

davidfowl · 2025-10-31T03:39:29Z

/backport to release/13.0

github-actions · 2025-10-31T03:39:39Z

Started backporting to release/13.0: https://github.com/dotnet/aspire/actions/runs/18961956932

github-actions · 2025-10-31T03:39:47Z

@davidfowl backporting to "release/13.0" failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: Added autoscale option for App Service Environment
Using index info to reconstruct a base tree...
M	src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs
M	src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentResource.cs
M	src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebsiteContext.cs
Falling back to patching base and 3-way merge...
Auto-merging src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs
CONFLICT (content): Merge conflict in src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs
Auto-merging src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentResource.cs
CONFLICT (content): Merge conflict in src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentResource.cs
Auto-merging src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebsiteContext.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 Added autoscale option for App Service Environment
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

Added autoscale option for App Service Environment

52ffd9a

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Oct 23, 2025

ShilpiR added 5 commits October 23, 2025 05:10

Testing with config properties for autoscale

a565d61

Adding separate config for ElasticWebAppScaleLimit. Setting dashboard…

5c1dae1

… instance count to test

Testing

92e6edb

Updated the autoscale settings and unit tests

8a588a5

Rename autoscale to automatic scaling

af7ba8d

ShilpiRach changed the title ~~[Testing in progress] Added autoscale option for App Service Environment~~ Enable automatic scaling for App Service Environment Oct 23, 2025

ShilpiR added 2 commits October 23, 2025 12:27

Removing unrelated changes

e13f1b0

Using term automatic scaling in public doc

a83e2d6

ShilpiRach marked this pull request as ready for review October 23, 2025 20:07

ShilpiRach requested review from captainsafia and eerhardt as code owners October 23, 2025 20:07

Copilot AI review requested due to automatic review settings October 23, 2025 20:07

Copilot AI reviewed Oct 23, 2025

View reviewed changes

mitchdenny added this to the Backlog milestone Oct 24, 2025

Turned default to false

638d691

Fixed comments

eb18842

ShilpiRach changed the title ~~Enable automatic scaling for App Service Environment~~ Add support to enable automatic scaling for App Service Environment Oct 24, 2025

ShilpiR and others added 6 commits October 24, 2025 04:53

comment fix

0fb1501

Merge branch 'main' into autoscale

2114375

Merge from main

bef864e

Merge

7533064

Fixing tests broken by merge from main

3d823ea

Merge branch 'main' into autoscale

edfe942

davidfowl approved these changes Oct 31, 2025

View reviewed changes

davidfowl merged commit 0a57ac6 into dotnet:main Oct 31, 2025
305 checks passed

dotnet-policy-service bot modified the milestones: Backlog, 13.0 Oct 31, 2025

Copilot AI mentioned this pull request Oct 31, 2025

Add automatic scaling support for Azure App Service Environment #12545

Draft

Add support to enable automatic scaling for App Service Environment #12305

Add support to enable automatic scaling for App Service Environment #12305

Uh oh!

Conversation

ShilpiRach commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Testing

Checklist

Uh oh!

github-actions bot commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mitchdenny commented Oct 24, 2025

Uh oh!

ShilpiRach commented Oct 24, 2025

Uh oh!

ShilpiRach commented Oct 24, 2025

Uh oh!

mitchdenny commented Oct 26, 2025

Uh oh!

tulikac commented Oct 27, 2025

Uh oh!

ShilpiRach commented Oct 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

btardif commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

davidfowl commented Oct 31, 2025

Uh oh!

github-actions bot commented Oct 31, 2025

Uh oh!

github-actions bot commented Oct 31, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ShilpiRach commented Oct 23, 2025 •

edited

Loading

github-actions bot commented Oct 23, 2025 •

edited

Loading

ShilpiRach commented Oct 27, 2025 •

edited

Loading

btardif commented Oct 29, 2025 •

edited

Loading