Autoscaling
Autoscaling
Autoscaling automatically adjusts the number of instances (replicas) of a service based on its CPU load: more traffic, more instances; a lull, back to the minimum.
Enabling autoscaling
In the service panel, Observability / Scaling tab:
| Parameter | Role |
|---|---|
| Min | Floor number of instances (never fewer) |
| Max | Ceiling on instances (never more) |
| CPU target (%) | Average utilization threshold that triggers adjustment |
Example: min 1, max 4, target 70%. If the average CPU across instances exceeds 70%, an instance is added (up to 4). Once the load drops back down for a sustained period, the excess instances are removed (down to 1).
Manual scaling
Without autoscaling, you set the number of replicas by hand in the same tab. Going from 1 to 2 instances doubles capacity and adds redundancy: an instance restart no longer takes the service down.
Application-side prerequisites
Multiple instances of your application run in parallel behind the same domain. Your code needs to be ready for this:
- No in-memory state shared across requests (sessions, local caches): externalize it to Redis or the database.
- Uploads and files: write to a persistent volume or object storage, not to the instance's local filesystem.
- WebSockets work, but a client is connected to one instance: broadcast messages across instances via Redis pub/sub if needed.
Choosing the right CPU target
- 70% is a good default: enough margin to absorb a spike while an instance starts up.
- A target that's too low (30%) scales too early and costs resources; too high (90%), the service saturates before reinforcement arrives.
- Watch actual behavior in the service metrics after enabling it.
The maximum number of instances remains bounded by your plan's limits (see Limits and resources).