Auto-scaling
Auto-scaling adjusts the number of spherelets running your service based on CPU load. You set a minimum, a maximum, and a CPU threshold; the platform takes over from there — adding spherelets when sustained CPU climbs past the threshold, and removing them when load drops.
Auto-scaling — one service, two snapshots
MinAt rest
1 sphereletCPU 20%
CPU > 80%
MaxUnder load
6 sphereletsCPU 85%
When CPU stays above your threshold, the platform adds spherelets up to your max. When traffic settles, it scales back down toward min.
You configure three things:
| Knob | What it controls |
|---|---|
| Min spherelets | The floor. The service never runs fewer than this — useful for always-on services that shouldn't cold-start. |
| Max spherelets | The ceiling. The platform won't add spherelets past this, even if load keeps climbing. Bounded by your account capacity. |
| CPU threshold | A percentage (e.g. 80). When average CPU across the service's spherelets stays above this, the platform scales out. |
Auto-scaling is a setting on the service, not the environment or project. Each service has its own range and threshold.
When to enable it
| Reason | Pick auto-scaling? |
|---|---|
| Traffic varies by time-of-day or by campaign | ✓ Yes |
| You want headroom for spikes without paying for it during quiet hours | ✓ Yes |
| Predictable, steady-state load | ✗ Just set a fixed spherelet count — auto-scaling adds complexity you don't need |
| Workload is bottlenecked on something other than CPU (database, external API) | ✗ Auto-scaling on CPU won't help — fix the bottleneck first |
How decisions are made
Two things shape every scaling decision:
- CPU is the only signal. The platform watches CPU utilization across the service's running spherelets. There is no memory threshold, no request-rate threshold, no custom metric.
- Sustained, not spiky. A brief CPU spike doesn't trigger scaling. CPU must stay above your threshold for a sustained window before the platform adds spherelets, and stay below for a sustained window before it removes them. This prevents flapping.
Two guardrails wrap the decision:
- Account capacity is the ceiling above your max. If your account has 10 spherelets remaining and your service's max is 20, the platform stops at 10 and surfaces a warning. Add capacity from Settings → Billing.
- Min protects steady-state. Setting min above zero keeps the service warm during quiet hours so a sudden spike doesn't hit a cold service.
Honest limits
A few things to know up front:
- CPU only. Memory, request rate, queue depth, and custom metrics are not supported as scaling signals today.
- One range per service. You can't define different ranges for different times of day. If your traffic pattern needs scheduled scaling (e.g. always 5 spherelets during business hours), set the min to 5 manually.
- Same shape across the range. Auto-scaling adds and removes spherelets of the service's shape — it doesn't promote a Flex service to Standard. To change shape, redeploy with a new shape; auto-scaling re-engages on the new shape.
- Health checks gate traffic, not scaling. A spherelet that fails its health check doesn't take traffic, but the platform still counts it against your range while it tries to come up. Fix the failing health check first if scale-up isn't helping.
Enable auto-scaling
On a new service
- Open the project and environment where the service should run.
- Click New service → pick a service kind (web service, worker).
- Pick a shape.
- In the Compute section, toggle Auto-scaling on.
- Set min spherelets, max spherelets, and the CPU threshold (default: 80%).
- Click Create.
On an existing service
- Open the service.
- Click Compute in the service sidebar.
- Toggle Auto-scaling on (or click Edit if it's already on).
- Adjust min / max / CPU threshold.
- Click Save.
Changes apply immediately — no redeploy needed.
What's next
- Spherelets — the underlying compute unit; shapes, count, and how scaling actually works.
- Lifecycle actions — start, stop, restart, redeploy — all interact with the spherelet count.
- Pricing — spherelets are billed monthly as capacity your account holds; auto-scaling controls how many of them run.