Min and max instances, concurrency, and CPU target - how container apps scale with traffic and scale to zero when idle to stop billing.
Scaling
Container apps scale horizontally: identical instances are added under load and removed when it passes. Four settings under Advanced shape that behaviour. Static sites have none of them - the CDN scales by itself.
How autoscaling decides#
Two signals add instances:
- Concurrency. Each instance serves at most its concurrency in parallel requests; when demand exceeds what the running instances can carry, more are started.
- CPU target. When average CPU across instances crosses the target, an instance is added even if concurrency has headroom.
Instances are removed as traffic falls, down to the minimum. Watch it happen on the Active instances chart - see Metrics.
Min instances#
Instances kept running even with no traffic.
- 0 (the default): the app sleeps when idle and stops billing. The first request after a quiet period pays a cold start - a few seconds while an instance boots.
- 1 or more: that many instances stay warm around the clock. No cold starts, billed while idle.
The Nano size can't stay warm - it always scales to zero. Pick a bigger size if you need a warm minimum.
Example: 1 for an API whose first request must be fast.
Tip
Scale to zero is what makes preview environments cheap: a preview nobody is looking at costs nothing. Keep previews at 0 and raise only production if cold starts hurt.
Max instances#
The autoscaling ceiling. However hard traffic spikes, you never run - or pay for - more than this many instances at once. The default ceiling is 10; choices go up to 100, and your plan sets an upper bound for the ceiling itself.
Example: 10
Concurrency#
How many requests a single instance handles at the same time (default 80).
Higher means fewer instances for the same traffic - cheaper, but each request shares the instance's memory and CPU with more neighbours. Lower gives each request more headroom; CPU-heavy or memory-hungry endpoints often want 10-20.
Each size has its own maximum:
| Size | Max concurrency |
|---|---|
| Nano | 40 |
| Micro | 80 |
| Small | 100 |
| Medium | 200 |
| Large | 300 |
Example: 80 for a typical I/O-bound API.
CPU target#
A new instance is added once average CPU across instances crosses this percentage (default 80%).
A higher target runs instances hotter before scaling out - cheaper, with less headroom for sudden spikes. A lower target scales earlier and absorbs bursts more smoothly.
Example: 70 for spiky traffic; 85 to squeeze cost on steady load.
Cold starts#
An app at zero instances boots one on the first request: the image starts, your server begins listening on its port, and the request is served. That is typically a few seconds, and it depends on your app - a lean server image cold-starts faster than one that loads heavy dependencies at startup.
Ways to spend it down:
- Set min instances to
1on the environments where it matters (usually just production). - Keep startup work lazy: connect to the database on first use rather than at boot.
- Keep the image lean - see Deploy with a Dockerfile for image-size advice.
The SSR policy#
Server-rendered frontends - Next.js, Nuxt, SvelteKit, Remix, Astro in SSR mode - have their shape pinned platform-wide: Micro size, scale 0-3, tier-1 region, always behind the edge CDN. The edge serves your audience; the origin only renders cache misses, so scaling knobs are hidden for these apps and the concurrency/CPU settings don't apply.