Scale a web component

Adjust how many instances of your HTTP application can run as CPU use, memory use, or HTTP demand changes. CPU- and memory-based scaling are available for development/test web apps with preview access. Configure a CPU target, a memory target, or both. You can also scale with HTTP demand or let an idle app scale to zero.

At a glance

• Scaling is app-owned policy, independent of version activation.
• Static content does not receive a compute scaling policy.
• Ordinary autoscaling keeps a positive minimum of instances (replicas) running.
• HTTP scaling can keep a positive minimum running, independently of CPU and memory targets.
• Minimum zero opts into scale-to-zero and always enables HTTP scaling.
• Portal edits saved policy separately from the current replica snapshot.
• App and subscription quotas can limit how many instances you can request.

Set policy

While settings load, placeholders reserve space for the toolbar and scaling controls.

1. In Portal, open your app and choose Application > Scaling. From Architecture, you can also select a web component, open its Scaling tab, and choose Open scaling settings.
2. If the active version has multiple web components, choose Component. A single web component is selected automatically.
3. Turn on Autoscaling. Without a saved policy, autoscaling is off and the platform uses one fixed replica. Turning the switch on prepares a draft; it does not save it.
4. Set Minimum replicas and Maximum replicas, or drag either end of the range slider. Tab between the minimum and maximum handles and use the arrow keys to adjust them. The handles cannot cross: the maximum must be greater than the minimum. The range description explains sleeping at zero and its required HTTP scaling signal.
5. Under Scaling signals, edit the CPU or memory utilization target. Use Add signal to add CPU, memory, or HTTP traffic, and the blue trash-can button to remove an optional signal.
6. Choose Save changes in the toolbar below the page description.

The example inputs shown when you enable autoscaling are editable suggestions, not sizing recommendations. A successful save confirms the policy; replica changes can take time. Save changes is disabled while any scaling field is invalid; correct the errors before saving.

A single banner above the toolbar summarizes unsaved changes and what saving will do: turn autoscaling on with the selected replica range and scaling signals, or turn it off and return the component to one replica. The banner is hidden while saving and returns if saving fails and the draft remains unsaved.

Reset discards unsaved changes and restores the latest loaded policy; it does not disable autoscaling. Refresh reloads saved settings, component information, and replica counts while preserving unsaved edits. If you switch components or navigate away with a draft, choose Stay to keep editing or Discard and continue to leave without saving. To save the draft, choose Stay and then Save changes in the toolbar.

For CPU-based scaling:

builder app scale update --name "<app-name>" \
  --subscription "<subscription-id>" --resource-group "<resource-group>" \
  --component "<web-component-name>" \
  --min 1 --max 5 --cpu-percent 70

For memory-based scaling:

builder app scale update --name "<app-name>" \
  --subscription "<subscription-id>" --resource-group "<resource-group>" \
  --component "<web-component-name>" \
  --min 1 --max 5 --memory-percent 80

To configure both targets, include --cpu-percent 70 and --memory-percent 80 in the same command. These values illustrate valid policy, not a sizing recommendation or capacity guarantee.

app scale update configures an autoscaling range rather than a fixed replica count. Equal bounds such as --min 1 --max 1 are not a supported mode of this command. Choose a maximum greater than the minimum; the CPU example above shows a valid policy shape.

Field / flag	Constraint
name / --component	Exact name of a non-static component
minReplicas / --min	Integer at least 0; 0 opts into scale-to-zero
maxReplicas / --max	Integer greater than minimum, at most 20
cpuUtilizationPercent / --cpu-percent	Optional integer from 1 to 100
memoryUtilizationPercent / --memory-percent	Optional integer from 1 to 100
httpEnabled / --http, --no-http	Optional Boolean; minimum 0 always enables HTTP

With a positive minimum, enable HTTP or supply at least one utilization target. CPU, memory, and HTTP selections can be combined. With minimum zero, the forced HTTP rule is sufficient. Policies do not select a different language, build toolchain, or compute size. The platform maximum of 20 is not a capacity guarantee. Your app and subscription quotas can impose lower limits. If an increase is rejected, reduce the requested maximum or contact your preview contact about the allowance. You can still scale down when usage is above the allowed limit.

Read replica counts

Target rollout required

Replica snapshots are not yet qualified for the shared preview targets. The status below applies where the replica-read API has been deployed; other targets show Replica count unavailable.

The component header shows a snapshot of its active deployment, read when the page opens, after a successful save, and when you choose Refresh. It does not continuously poll or send requests to wake an idle app.

• N running · M not ready counts readiness separately for each replica. For example, two ready replicas and one starting replica show 2 running · 1 not ready. The not-ready count appears only when it is greater than zero.
• A running replica and its application container are running, started, and ready according to the runtime provider. Not ready means that readiness was not confirmed; it does not establish inactivity or explain why the replica is not ready.
• 0 running means a successful read found no replicas; it does not mean the read failed.
• N replicas · readiness unavailable means the count is known but replica identities could not be verified well enough to report a readiness breakdown.
• Replica count unavailable means the read failed or there is no matching active compute deployment. A failed refresh removes the previous count rather than presenting it as current.

These counts describe the last runtime snapshot, not continuous monitoring or an end-to-end availability guarantee. Open your app's URL to verify its behavior. Reading replica counts does not change your saved policy or unsaved edits.

HTTP autoscaling without sleeping

In Portal, turn on Autoscaling, set a positive minimum and a higher maximum, then use Add signal > HTTP traffic and Save changes. CPU and memory targets are optional when HTTP is on. CLI example:

builder app scale update --name "<app-name>" \
  --subscription "<subscription-id>" --resource-group "<resource-group>" \
  --component "<web-component-name>" \
  --min 1 --max 10 --http

This keeps at least one instance running and lets HTTP demand recommend scale-out up to ten, subject to service limits. The platform manages the HTTP target, currently defaulting to 100 requests/sec; there is no customer request-rate setting. This target is not a traffic limit or capacity guarantee.

Choose the Remove HTTP traffic trash-can button, or use --no-http, to remove optional HTTP scaling. Keep a CPU or memory target for a positive-minimum autoscaling policy. To restore one fixed instance, turn Autoscaling off and choose Save changes, or use --disable.

Scale to zero

Choose suitable workloads

Scale-to-zero requires an image-backed app version. Requests can be interrupted when an app goes to sleep. Keep a positive minimum for long-running requests, streams, or background work.

In Portal, set Minimum replicas to 0 and keep the desired maximum. The HTTP traffic signal is required and cannot be removed while the minimum is zero. Choose Save changes to apply the policy. CLI example:

builder app scale update --name "<app-name>" \
  --subscription "<subscription-id>" --resource-group "<resource-group>" \
  --component "<web-component-name>" \
  --min 0 --max 10

This policy permits zero instances when idle and up to ten while active, subject to the effective service limits. The active version must use an image-backed deployment. Existing defaults do not change. An ineligible active version is rejected before the saved scaling policy changes. Both --min 0 --max 1 and zero-to-many policies are valid without utilization targets.

The service automatically adds an HTTP activity rule for zero-minimum apps; there is no separate HTTP enablement step. While requests are arriving, CPU/memory and HTTP rules can recommend instance counts. An omitted or false httpEnabled does not disable HTTP when the minimum is zero. To keep HTTP scaling but stop sleeping, use a positive minimum with --http.

After roughly five to six minutes without new HTTP requests, the app can go to sleep. The next request waits for it to start again. The inactivity window is provider-owned and is not configurable. Each wake starts a fresh process. Disk-only snapshots preserve local files best effort and can fall back to a cold start. Instances have independent local files; snapshots do not provide shared storage or a persistence guarantee. Keep durable and shared data in external storage.

A request already running when the app goes to sleep can be interrupted, even if it takes only a few seconds. Retrying a failed write can repeat its work. Background work and open SSE/WebSocket connections do not prevent sleep. Health requests can keep the app awake.

To disable scale-to-zero, remove the component's policy and restore one running instance:

builder app scale update --name "<app-name>" \
  --subscription "<subscription-id>" --resource-group "<resource-group>" \
  --component "<web-component-name>" --disable

In Portal, turn Autoscaling off and choose Save changes to remove the selected component's policy. The warning explains that saving returns the component to one replica. Both paths preserve other components' policies and do not create a new version or deployment. They remain available when the service stops admitting new scale-to-zero policies.

ARM configuration

Scaling is written through app PUT in properties.scaling.components, not through the current sparse source/variables PATCH shape:

{
  "location": "<existing-app-location>",
  "properties": {
    "scaling": {
      "components": [
        {
          "name": "<web-component-name>",
          "minReplicas": 1,
          "maxReplicas": 5,
          "cpuUtilizationPercent": 70,
          "memoryUtilizationPercent": 80
        }
      ]
    }
  }
}

Read the existing desired app configuration and preserve other writable fields when constructing PUT. Do not copy read-only runtime fields into the request. The CLI performs a read-before-write for this operation. To enable HTTP scaling, add "httpEnabled": true to the component policy. Setting "minReplicas": 0 always enables HTTP scaling, even when httpEnabled is omitted or false.

Deployments changes the serving version; scaling changes policy independently. The limits reference summarizes validation ceilings, not guaranteed target capacity.