Scaling and compute
Adjust instance size and replica counts to match your application's resource needs.
Openstead offers instance plans and replica settings for application workloads. Increasing an instance's resources and adding more instances solve different problems: a memory-heavy single task may need a larger instance, while independent HTTP requests or queue jobs may benefit from more instances.
Change instance size
Open the service's Compute page and review the available plan, quote, and effective date. Complete any required payment before deployment. A change purchased during an existing paid month takes effect at that month's end; it does not immediately replace the current paid configuration. See Renewals and plan changes before scheduling a capacity change.
When the new configuration is active and eligible for deployment, deploy it and compare memory and CPU usage with the previous release.
Plan selection in a form does not activate paid resources by itself. Use the service's billing and deployment status to confirm what is actually running.
Manual replicas
Paid web services, private services, and background workers can use multiple instances where capacity permits. Set the replica count, save, and deploy. The configuration accepts counts from 1 to 20, but the workspace must have capacity and billing authorization for the requested resources.
Free instances cannot be scaled. Services with a local persistent disk require one instance. Managed databases have their own compute and storage rules; this replica setting is not database replication.
Automatic scaling
For an eligible paid service without a persistent disk:
- Set Scaling mode to Automatic.
- Choose minimum and maximum instances.
- Set target CPU and memory utilization.
- Review the resource quote, save the policy, and deploy.
Autoscaling uses sustained observed CPU or memory utilization, not a single spike. It increases or decreases the desired count gradually and uses cooldowns to reduce oscillation. Missing or stale samples do not trigger a scale-down.
Scaling stays within the configured bounds and available workspace capacity. It does not provision unlimited underlying capacity on demand. If capacity prevents the requested change, the service reports the issue; contact support or reduce the request.
Make the application safe for replicas
- Store sessions in a shared store or signed cookies rather than instance memory.
- Store uploads in object storage instead of a local instance filesystem.
- Use database connection-pool limits that account for every instance.
- Keep scheduled tasks in a separate cron job so each web replica does not run the same schedule.
- Make queue jobs safe to repeat and confirm multiple consumers are supported.
For server-rendered frameworks, also review cache consistency and release-specific state. Adding replicas does not automatically make an application designed for one process distributed.
Inspect the result
The scaling panel distinguishes confirmed instances from desired instances. Wait for the operation to converge and check application health. A saved policy is applied on the next deployment; it is not an immediate change to the current release.
Review Logs and metrics before scaling further. More resources can mask a leak or a slow query without fixing it.