Autoscaling & scale-to-zero
Container apps scale in one of two ways depending on the plan. Static sites do not scale — they are served from the CDN with no pod — so this page is about container apps.
Two scaling modes, mutually exclusive
Section titled “Two scaling modes, mutually exclusive”| Mode | Plan | Behaviour |
|---|---|---|
| KEDA scale-to-zero | Free tier | Single replica, scales to 0 after idle, cold-starts on the next request |
| HPA autoscaling | Paid tiers | Always-warm, adds and removes replicas based on load |
These two modes are mutually exclusive. When HPA autoscaling is enabled the app is always-warm and never sleeps; when it is off (free tier) the app scales to zero. You cannot have both.
Both a non-free compute tier and HPA autoscaling require an active paid plan. The create path checks isOrgPaid, so a raw API caller cannot enable autoscaling or a paid tier on a free organization.
Free tier: scale-to-zero and cold starts
Section titled “Free tier: scale-to-zero and cold starts”A free-tier container runs a single replica. After a period of no traffic, KEDA scales it down to zero — no pod runs, so it costs nothing. On the next incoming request the app cold-starts: KEDA wakes it, which adds a few seconds of latency to that first request. Subsequent requests hit the warm pod.
This is the trade-off that makes the free tier free: your app sleeps when idle. Only the free tier sleeps — every paid tier is always-on.
Paid tiers: always-warm HPA autoscaling
Section titled “Paid tiers: always-warm HPA autoscaling”On a paid tier you can enable HPA (Horizontal Pod Autoscaler) autoscaling. The app stays always-warm (no cold starts) and Kubernetes scales the replica count up and down based on load. You configure:
| Setting | Meaning |
|---|---|
| Min replicas | The floor — the app never drops below this (always-warm) |
| Max replicas | The ceiling — the app never scales above this |
| Target CPU | The CPU utilization the autoscaler aims to hold; it adds replicas when utilization exceeds the target and removes them when it drops |
Smart defaults for paid auto-detect
Section titled “Smart defaults for paid auto-detect”When a paid organization deploys via auto-detect and the repo lands on the container path, PandaStack applies production-friendly defaults automatically: the standard tier (1 vCPU / 2 GB) with HPA autoscaling enabled (always-warm). A free org always gets the free-tier default (free compute + KEDA scale-to-zero).
Changing scaling triggers a redeploy
Section titled “Changing scaling triggers a redeploy”Autoscaling is part of a container’s compute configuration, alongside the tier and disk. Changing any of them triggers a redeploy — the worker re-renders the Helm chart and rolls out the new configuration.
Because a free-tier container scales to zero, an idle free app costs $0. Paid tiers are always-on and metered as container-hours; enabling autoscaling means you pay for the running replicas. See Usage & metering and Instance tiers.
Related
Section titled “Related”- Container apps
- Auto-detect deploys — paid smart defaults
- Instance tiers
- Plans & limits