Instances and automatic scaling.
Run several instances of a web service so it keeps answering during restarts and under load, or let the number follow the load — and how both are billed.
An instance is one running copy of your web service. With more than one, visitors are shared among them, and the application keeps answering while one of them restarts.
Instances are set in the service's Settings → Instances. They apply to web services — the main application and web services of a project — not to background workers, scheduled jobs or databases.
A fixed number
Choose Fixed number and set Number of instances — from 1 to 10. Each instance runs with the same memory and CPU as the service.
Price: each instance is billed like the service itself. A service at $10 a month with 3 instances costs $30 a month. The difference for the current month is prorated.
Automatic scaling
Choose Automatic scaling and set:
- Minimum — always running.
- Maximum — never more than this.
- CPU target — the processor load to keep each instance at (we suggest 70%).
One more instance starts when the load stays above the target for 3 minutes; one stops when the load stays below it for 10 minutes. A new instance receives visitors only once it answers. If the service runs at its maximum and is still busy for 15 minutes, we let you know, so you can raise the maximum.
Price: the minimum is billed every month like a fixed number of instances. Each instance running above the minimum is billed by the hour it actually runs — the service's monthly price divided by 730 hours. For a $10 service that is about $0.0137 per instance-hour. These instance-hours are added to the project's next payment.
The panel shows how many instances are running now and the instance-hours above the minimum so far this month.
When it's worth it
- Two instances keep the site answering during restarts, and spread the load of a busy site.
- Automatic scaling suits traffic with peaks — a campaign, a launch, a busy evening — without paying for the peak all month.
Sessions and files with several instances
Requests are spread across the instances, so a visitor's next request may reach a different one. Each instance has its own files, so keep anything all of them must see outside them:
- Sessions — in Valkey or the database. A Laravel application with Valkey keeps its sessions and cache there automatically; without Valkey, set
SESSION_DRIVER=database. - Uploads — in object storage.
The panel warns when a Laravel service with sessions in files runs several instances. A service that keeps files in its data folder runs all its instances on the same server.
Calls from other services
Other services of the application reach a service with several instances at its Internal address, and their connections are spread among the running instances. Use short timeouts and retry reading requests once or twice — an instance may stop during a deploy or when automatic scaling removes it. See Service-to-service communication.
Keeping spending predictable
A project's monthly spending limit can pause extra usage once it is reached: running services keep their resources, while extra instances wait until next month or until you raise the limit. See Billing for applications.
Monitoring with several instances
The Monitoring tab shows memory and processor use of all instances together, with the limit multiplied by the number of instances, and an Instances chart of how many ran. See Monitoring and logs.